Re: [Intel-gfx] [RFC] GPU reset notification interface
On Tue, 17 Jul 2012 15:16:19 -0700, Ian Romanick i...@freedesktop.org wrote:
I'm getting ready to implement the reset notification part of
GL_ARB_robustness in the i965 driver. There are a bunch of quirky bits
of the extension that are causing some grief in designing the kernel /
user interface. I think I've settled on an interface that should meet
all of the requirements, but I want to bounce it off people before I
start writing code.
What's the rationale for reset-in-progress? The actual delay between a
hang being noticed and the reset worker kicked off is going to be
very, very small -- in theory there is no window of opportunity for
another client to sneek and perform more work.
If we replace 'index' with breadcrumb, I'm much happier. Then you
have
struct drm_i915_reset_counts {
u32 num_resets;
u32 last_reset; /* using the seqno breadcrumb */
u32 flags; /* 0x1 if in progress */
u32 num_contexts;
struct drm_i915_context_reset_counts contexts[0];
};
struct drm_i915_context_reset_counts {
u32 ctx_id; /* per-fd namespace */
u32 num_resets;
u32 last_reset; // seqno
u32 num_guilty;
u32 last_guilty; // seqno
/*
u32 num_innocent;
u32 last_innocent;
u32 num_unproven;
u32 last_unproven;
*/
};;
So what do the terms mean as far as we are aware?
guilty - this context owned the batch we determine the GPU is executing
innocent - this context owns buffer that were on the active list at the
time of execution and presumed trashed with the reset, i..e
the context itself was on the active list.
unproven - a hang occurred in the driver without any indication of a
guilty party (e.g. a semaphore hang due to bad olr), and
this context was on the active list.
If we only increment the reset counter for a context if it is active at
the time of reset, then
num_resets = num_guiltly + num_innocent + num_unproven;
and we can drop num_unproven. Since there is then no difference in
effect between unproven/innocence, we need only report the last time it
was found guilty and the total number of reset events involving this
context.
Similarly, the per-fd global counter is only incremented if one of its
contexts was active at the time of an event. The presumption being that
userspace does the broadcast across shared buffers/contexts to other
processes and updates the shared buffers as necessary.
We only keep 'monotonically' increasing state, so userspace is
responsible for computing deltas to catch events.
For the breadcrumb I'd just to use the seqno. It matters not to
userspace that the event breadcrumb jumps by more than one between
events, as it only sees a compressed view anyway (i.e. there may be
external resets that it knows nothing about).
The largest uncertainity for me is the guilty/innocence/unknown
counters and the value of providing both innocent and unproven. Then
there is the question whether we track/report resets that are nothing to
do with the fd. And whether contexts or buffers is more meaningful. From
a tracking perspective, contexts wins both for the kernel, and
presumably for userspace. And given a queriable last_write_seqno for
userspace, it can easily convert a context reset seqno into a trash
list.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] GPU reset notification interface
On Tue, Jul 17, 2012 at 03:16:19PM -0700, Ian Romanick wrote:
I'm getting ready to implement the reset notification part of
GL_ARB_robustness in the i965 driver. There are a bunch of quirky
bits of the extension that are causing some grief in designing the
kernel / user interface. I think I've settled on an interface that
should meet all of the requirements, but I want to bounce it off
people before I start writing code.
Here's the list of requirements.
- Applications poll for reset status.
- Contexts that did not lose data or rendering should not receive a
reset notification. This isn't strictly a requirement of the spec,
but it seems like a good practice. Once an application receives a
reset notification for a context, it is supposed to destroy that
context and start over.
- If one context in an OpenGL share group receives a reset
notification, all contexts in that share group must receive a reset
notification.
- All contexts in a single GL share group will have the same fd.
This isn't a requirement so much as a simplifying assumption. All
contexts in a share group have to be in the same address space, so I
will assume that means they're all controlled by one DRI driver
instance with a single fd.
- The reset notification given to the application should try to
assign guilt. There are three values possible: unknown guilt,
you're not guilty, or you are guilty.
- If there are multiple resets between polls, the application should
get the most guilty answer. In other words, if there are two
resets and the context was guilty for one and not the other, the
application should get the guilty notification.
- After the application polls the status, the status should revert
to no reset occurred.
- If the application polls the status and the reset operation is
still in progress, it should continue to get the reset value until
it is safe to begin issuing GL commands again.
At some point I'd like to extend this to give slightly finer grained
mechanism so that a context could be told that everything after a
particular GL sync (fence) operation was lost. This could prevent
some applications from having to destroy and rebuild their context.
This isn't a requirement, but it's an idea that I've been mulling.
Each time a reset occurs, an internal count is incremented. This
associates a unique integer, starting with 1, with each reset event.
Each context affected by the reset will have the reset event ID
stored in one its three guilt levels. An ioctl will be provided
that returns the following data for all contexts associated with a
particular fd.
In addition, it will return the index of any reset operation that is
still in progress.
I think this should be sufficient information for user space to meet
all of the requirements. I had a conversation with Paul and Ken
about this. Paul was pretty happy with the idea. Ken felt like too
little policy was in the kernel, and the resulting interface was too
heavy (I'm paraphrasing).
A few things:
- I agree with Chris that reset_in_progress should go, if userspace can
sneak in and witness a reset event, we have a bug in the kernel. Since
very recently, we actually have a few bugs less in that area ;-)
- The all contexts in a share group need to receive a reset notification
wording is irking me a bit because we currently only track all the
actively used things. So if another context in that share group isn't
affected (i.e. doesn't even use any of the potentially corrupted bos),
is the idea that the kernel grows the required tracking, or should
userspace always ask the reset state for all contexts and do the math
itself?
- The above essentially links in with how we blame the guilt and figure
out who's affected. Especially when there's no hw context around, e.g.
on the blitter or bsd rings, or when an object is used by another
process and gets corrupted there. Does the spec make any guarantees for
such a case? Or should we just blame an unknown_reset for all the
contexts that belong to the fd that submitted the bad batch.
As an idea for the above two issues, what about the kernel also keeps a
per-fd reset statistics, which will also be returned with this ioctl?
We'd then restrict the meaning of the ctx fields to only mean and the
context was actually active. Userspace could then wrap all the per-fd
hang reports into reset_unknown for arb_robustness, but I think this would
be a bit more flexible for other userspace.
struct drm_context_reset_counts {
__u32 ctx_id;
/**
* Index of the most recent reset where this context was
* guilty. Zero if none.
*/
__u32 ctx_guilty;
/**
* Index of the most recent reset where this context was active,
* not guilty. Zero if none.
*/
__u32 ctx_not_guilty;
/**
* Index of the most recent reset where this context was active,
Re: [Intel-gfx] [PATCH 2/2] drm/i915: add port field to struct intel_dp and use it
On Tue, Jul 17, 2012 at 05:53:45PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com This will be needed for Haswell, but already has its uses here. This patch started as a small patch written patch by Shobhit Kumar, but it has changed so much that none of its original lines remain. Credits-to: Shobhit Kumar shobhit.ku...@intel.com Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Both patches queued for -next, thanks. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote: On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen knut_peter...@t-online.de wrote: Some XAA code still waits for a sudden death: [ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP Ok, pushed yet another patch to reimplement those tables within i810. I couldn't spot any more obvious XAA functions called from i810_accel, so hopefully this will be the last iteration! Sigh. Wish you hadn't, the linker behaviour he's seeing is _broken_. Just because we don't know why doesn't make it not a bug. - ajax signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
On Wed, 18 Jul 2012 10:02:08 -0400, Adam Jackson a...@redhat.com wrote: On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote: On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen knut_peter...@t-online.de wrote: Some XAA code still waits for a sudden death: [ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP Ok, pushed yet another patch to reimplement those tables within i810. I couldn't spot any more obvious XAA functions called from i810_accel, so hopefully this will be the last iteration! Sigh. Wish you hadn't, the linker behaviour he's seeing is _broken_. Just because we don't know why doesn't make it not a bug. Except it also meant that i810 was indeed broken since it was unusing undefined symbols. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
On Wed, 2012-07-18 at 15:07 +0100, Chris Wilson wrote: On Wed, 18 Jul 2012 10:02:08 -0400, Adam Jackson a...@redhat.com wrote: On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote: On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen knut_peter...@t-online.de wrote: Some XAA code still waits for a sudden death: [ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP Ok, pushed yet another patch to reimplement those tables within i810. I couldn't spot any more obvious XAA functions called from i810_accel, so hopefully this will be the last iteration! Sigh. Wish you hadn't, the linker behaviour he's seeing is _broken_. Just because we don't know why doesn't make it not a bug. Except it also meant that i810 was indeed broken since it was unusing undefined symbols. No, not the case. Normal ELF behaviour is that external data references are resolved at object load time, but that function references are resolved when they are first called; this is an optimization for app startup time. The former case is not what's going on here, because we're not taking the address of XAAGetPatternROP (a data reference), we're calling it (a function reference): hate:~/driver/xf86-video-intel% git grep XAAGetPatternROP src/legacy/i810/i810_accel.c: (XAAGetPatternROP(rop) 16) | src/legacy/i810/i810_xaa.c: pI810-BR[13] |= XAAGetPatternROP(rop) 16; So those should resolve lazily, which means if you never call them they never _need_ to resolve. And this is how X drivers normally work, notice that libfb isn't loaded _before_ you load your driver but yet the driver loads. And we know the failure case here is not failing to lazily resolve, because if we were hitting _that_ we wouldn't see the error message he's seeing, ld.so would just bitch on stderr and _exit(). The error message he's seeing is dlopen() failing. So this really honestly is a toolchain problem, not a driver problem. Knut, can you send me a copy of your driver binary? I'm really curious to see where that data reference is coming from, assuming BIND_NOW is not what we're seeing. - ajax signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
On Wed, 18 Jul 2012 10:29:26 -0400, Adam Jackson a...@redhat.com wrote: So those should resolve lazily, which means if you never call them they never _need_ to resolve. And this is how X drivers normally work, notice that libfb isn't loaded _before_ you load your driver but yet the driver loads. They were being used by i810_dri.c, so i810 was busted. It just happened to be that the first user to spot this was not using i810. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/81] drm/fb helper: don't call drm_crtc_helper_set_config
Hi Dave,
Can you please pick this one up for -next? There are a few other issues
where the fb helper is a bit too intimate with the crtc helper (i.e. it
depends upon callbacks and behaviour only provided when using the crtc
helpers). But this one here is the only one I can't work around in i915.ko
and hence would block merging the modeset rewrite for 3.7.
I've put a todo down to untangle the fb helper a bit better from the crtc
helper, but that's for a later patch series.
Yours, Daneil
PS: Can you also pick up the other drm patch in this series? That unused
list_head confused me quite a bit until I've noticed that it's ... unused.
On Wed, Jul 11, 2012 at 04:28:07PM +0200, Daniel Vetter wrote:
Go through the interface vtable instead, because not everyone might be
using the crtc helper code.
Cc: dri-de...@lists.freedesktop.org
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_fb_helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5683b7f..bf97c0a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -228,7 +228,7 @@ bool drm_fb_helper_restore_fbdev_mode(struct
drm_fb_helper *fb_helper)
int i, ret;
for (i = 0; i fb_helper-crtc_count; i++) {
struct drm_mode_set *mode_set =
fb_helper-crtc_info[i].mode_set;
- ret = drm_crtc_helper_set_config(mode_set);
+ ret = mode_set-crtc-funcs-set_config(mode_set);
if (ret)
error = true;
}
--
1.7.7.6
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/81] drm/fb helper: don't call drm_crtc_helper_set_config
Actually including Dave on the recipient list might work bettter ;-)
On Wed, Jul 18, 2012 at 05:49:22PM +0200, Daniel Vetter wrote:
Hi Dave,
Can you please pick this one up for -next? There are a few other issues
where the fb helper is a bit too intimate with the crtc helper (i.e. it
depends upon callbacks and behaviour only provided when using the crtc
helpers). But this one here is the only one I can't work around in i915.ko
and hence would block merging the modeset rewrite for 3.7.
I've put a todo down to untangle the fb helper a bit better from the crtc
helper, but that's for a later patch series.
Yours, Daneil
PS: Can you also pick up the other drm patch in this series? That unused
list_head confused me quite a bit until I've noticed that it's ... unused.
On Wed, Jul 11, 2012 at 04:28:07PM +0200, Daniel Vetter wrote:
Go through the interface vtable instead, because not everyone might be
using the crtc helper code.
Cc: dri-de...@lists.freedesktop.org
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_fb_helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
index 5683b7f..bf97c0a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -228,7 +228,7 @@ bool drm_fb_helper_restore_fbdev_mode(struct
drm_fb_helper *fb_helper)
int i, ret;
for (i = 0; i fb_helper-crtc_count; i++) {
struct drm_mode_set *mode_set =
fb_helper-crtc_info[i].mode_set;
- ret = drm_crtc_helper_set_config(mode_set);
+ ret = mode_set-crtc-funcs-set_config(mode_set);
if (ret)
error = true;
}
--
1.7.7.6
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] vgaarb: call pci_disable|enable_device on decoding vga devices
Hi Dave,
This one plus the pci_disable_device and related error path cleanups are
part of the series to move the agp setup into drivers.
I've implemented your suggestion to work around the midlayer, so drm/i915
doesn't block for this at all. But I still think this is the right way to
solve this. Shall I resend all these patches so you have them in context?
Yours, Daniel
On Fri, Jun 08, 2012 at 06:20:39PM +0200, Daniel Vetter wrote:
There's the neat little problem that some systems die if vga decoding
isn't decoded anywhere, because linux disabled that pci device.
Atm we solve that problem by simple not calling pci_disable_device at
driver unregister time for drm pci devices. Which isn't to great
because it leaks a pci_enable_device reference on module reload and
also is rather inconsistent, since the driver load codcode in
drm/drm_pci.c _does_ call pci_disable_device on the load error path.
To fix this issue, let the vga arbiter hold a pci_enable_device
reference on its own when the vga device decodes anything. This leaves
the issue still open when the vga arbiter isn't loaded/compiled in,
but I guess since drm module unload is riddled with dragons it's ok to
say just don't do this.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/vga/vgaarb.c | 27 +--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 3df8fc0..82f19a1 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -49,7 +49,11 @@
static void vga_arbiter_notify_clients(void);
/*
* We keep a list of all vga devices in the system to speed
- * up the various operations of the arbiter
+ * up the various operations of the arbiter. Note that vgaarb keeps a
+ * pci_enable_device reference for all vga devices with owns != 0. This is to
+ * avoid drm devices from killing the system when they call
pci_disable_device
+ * on module unload (as they should), because some systems don't like it if
no
+ * one decodes vga.
*/
struct vga_device {
struct list_head list;
@@ -171,7 +175,7 @@ static struct vga_device *__vga_tryget(struct vga_device
*vgadev,
{
unsigned int wants, legacy_wants, match;
struct vga_device *conflict;
- unsigned int pci_bits;
+ unsigned int pci_bits, ret;
u32 flags = 0;
/* Account for normal resources to lock. If we decode the legacy,
@@ -264,6 +268,10 @@ static struct vga_device *__vga_tryget(struct vga_device
*vgadev,
pci_set_vga_state(conflict-pdev, false, pci_bits, flags);
conflict-owns = ~lwants;
+
+ if (conflict-owns == 0)
+ pci_disable_device(conflict-pdev);
+
/* If he also owned non-legacy, that is no longer the case */
if (lwants VGA_RSRC_LEGACY_MEM)
conflict-owns = ~VGA_RSRC_NORMAL_MEM;
@@ -290,6 +298,12 @@ enable_them:
if (!!(wants VGA_RSRC_LEGACY_MASK))
flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
+ if (vgadev-owns == 0) {
+ ret = pci_enable_device(vgadev-pdev);
+ if (ret)
+ return ERR_PTR(ret);
+ }
+
pci_set_vga_state(vgadev-pdev, true, pci_bits, flags);
if (!vgadev-bridge_has_one_vga) {
@@ -376,6 +390,8 @@ int vga_get(struct pci_dev *pdev, unsigned int rsrc, int
interruptible)
if (conflict == NULL)
break;
+ if (IS_ERR(conflict))
+ return PTR_ERR(conflict);
/* We have a conflict, we wait until somebody kicks the
* work queue. Currently we have one work queue that we
@@ -513,6 +529,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev
*pdev)
unsigned long flags;
struct pci_bus *bus;
struct pci_dev *bridge;
+ int ret;
u16 cmd;
/* Only deal with VGA class devices */
@@ -582,6 +599,12 @@ static bool vga_arbiter_add_pci_device(struct pci_dev
*pdev)
vga_arbiter_check_bridge_sharing(vgadev);
+ if (vgadev-owns != 0) {
+ ret = pci_enable_device(vgadev-pdev);
+ if (ret)
+ goto fail;
+ }
+
/* Add to the list */
list_add(vgadev-list, vga_list);
vga_count++;
--
1.7.7.6
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: set IDICOS to medium uncore resources
Chris Wilson ch...@chris-wilson.co.uk writes: On Mon, 18 Jun 2012 10:35:54 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Fri, May 04, 2012 at 06:58:59PM -0700, Ben Widawsky wrote: I'm seeing about a 5% FPS improvement across various benchmarks on my IVB i3. Rumor has it that the higher end parts show even more benefit. This derives from a patch originally given to me by Bernard. The docs are confusing about the definition names (ie. medium really seems like max), but it would seem it gives more cache to the GT at the expense of uncore. This configuration makes the split most in favor of the GT. I've not tried the other IDICOS values. Cc: Kilarski, Bernard R bernard.r.kilar...@intel.com Signed-off-by: Ben Widawsky b...@bwidawsk.net Queued for -next, with Eric's ack added. Although I've had fix the patch, it didn't compile :( So this introduces a 10% (205 to 185 fps on an i7-3720qm @10x7) performance regression on good old CPU bound padman, but one large win with alpha compositing the same texture over and over again (fishtank 7.8s to 6.8s). Oh well, there's plenty of overhead in mesa to recover -- reading the profiles it is rate limited by the cpu overhead in i965_dri.so. Yeah, the plan for CPU overhead is threading the dispatch -- it's what every other driver does. pgpA2Vovxjc3G.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] GPU reset notification interface
On 07/18/2012 02:20 AM, Daniel Vetter wrote: On Tue, Jul 17, 2012 at 03:16:19PM -0700, Ian Romanick wrote: I'm getting ready to implement the reset notification part of GL_ARB_robustness in the i965 driver. There are a bunch of quirky bits of the extension that are causing some grief in designing the kernel / user interface. I think I've settled on an interface that should meet all of the requirements, but I want to bounce it off people before I start writing code. Here's the list of requirements. - Applications poll for reset status. - Contexts that did not lose data or rendering should not receive a reset notification. This isn't strictly a requirement of the spec, but it seems like a good practice. Once an application receives a reset notification for a context, it is supposed to destroy that context and start over. - If one context in an OpenGL share group receives a reset notification, all contexts in that share group must receive a reset notification. - All contexts in a single GL share group will have the same fd. This isn't a requirement so much as a simplifying assumption. All contexts in a share group have to be in the same address space, so I will assume that means they're all controlled by one DRI driver instance with a single fd. - The reset notification given to the application should try to assign guilt. There are three values possible: unknown guilt, you're not guilty, or you are guilty. - If there are multiple resets between polls, the application should get the most guilty answer. In other words, if there are two resets and the context was guilty for one and not the other, the application should get the guilty notification. - After the application polls the status, the status should revert to no reset occurred. - If the application polls the status and the reset operation is still in progress, it should continue to get the reset value until it is safe to begin issuing GL commands again. At some point I'd like to extend this to give slightly finer grained mechanism so that a context could be told that everything after a particular GL sync (fence) operation was lost. This could prevent some applications from having to destroy and rebuild their context. This isn't a requirement, but it's an idea that I've been mulling. Each time a reset occurs, an internal count is incremented. This associates a unique integer, starting with 1, with each reset event. Each context affected by the reset will have the reset event ID stored in one its three guilt levels. An ioctl will be provided that returns the following data for all contexts associated with a particular fd. In addition, it will return the index of any reset operation that is still in progress. I think this should be sufficient information for user space to meet all of the requirements. I had a conversation with Paul and Ken about this. Paul was pretty happy with the idea. Ken felt like too little policy was in the kernel, and the resulting interface was too heavy (I'm paraphrasing). A few things: - I agree with Chris that reset_in_progress should go, if userspace can sneak in and witness a reset event, we have a bug in the kernel. Since very recently, we actually have a few bugs less in that area ;-) I'm operating under the assumption that, from user space's perspective, resets are not instantaneous. If resets are instantaneous, that may change things. I had envisioned two potential uses for reset_in_progress, but I've managed to talk myself out of both. - The all contexts in a share group need to receive a reset notification wording is irking me a bit because we currently only track all the actively used things. So if another context in that share group isn't affected (i.e. doesn't even use any of the potentially corrupted bos), is the idea that the kernel grows the required tracking, or should userspace always ask the reset state for all contexts and do the math itself? There are a couple reasons that all contexts in a share group need to get the reset notification. Consider an application with two contexts, A and B. Context A is a worker context that does a bunch of render-to-texture operations, and context B will eventually consume those textures. If context A receives a reset, context B, even if it hasn't done any rendering in five minutes, has lost data. The kernel should never have any knowledge about GL share groups. This is where my simplifying assumption (that all contexts in a share group share an address space and an fd) comes in handy. If context A queries the reset status from the kernel first, it can reach over and poke the reset status of context B (in the gl_context structure). Likewise, if context B queries the kernel first, it can see that another kernel context in its GL context share group got reset. - The above essentially links in with how we blame the guilt and figure out who's affected. Especially when there's no hw context
Re: [Intel-gfx] [RFC] GPU reset notification interface
On Wed, 2012-07-18 at 09:23 -0700, Ian Romanick wrote: On 07/18/2012 02:20 AM, Daniel Vetter wrote: A few things: - I agree with Chris that reset_in_progress should go, if userspace can sneak in and witness a reset event, we have a bug in the kernel. Since very recently, we actually have a few bugs less in that area ;-) I'm operating under the assumption that, from user space's perspective, resets are not instantaneous. If resets are instantaneous, that may change things. Do they need to be instantaneous, or do they merely need to be atomic-and-reasonably-quick? Could just block new ioctl submission until the reset completes. - ajax signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] GPU reset notification interface
On Wed, Jul 18, 2012 at 6:36 PM, Adam Jackson a...@redhat.com wrote: On Wed, 2012-07-18 at 09:23 -0700, Ian Romanick wrote: On 07/18/2012 02:20 AM, Daniel Vetter wrote: A few things: - I agree with Chris that reset_in_progress should go, if userspace can sneak in and witness a reset event, we have a bug in the kernel. Since very recently, we actually have a few bugs less in that area ;-) I'm operating under the assumption that, from user space's perspective, resets are not instantaneous. If resets are instantaneous, that may change things. Do they need to be instantaneous, or do they merely need to be atomic-and-reasonably-quick? Could just block new ioctl submission until the reset completes. That's actually what we already do, that block ioctls until reset completes thing ;-) -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] GPU reset notification interface
On Wed, Jul 18, 2012 at 09:23:46AM -0700, Ian Romanick wrote:
On 07/18/2012 02:20 AM, Daniel Vetter wrote:
- The all contexts in a share group need to receive a reset notification
wording is irking me a bit because we currently only track all the
actively used things. So if another context in that share group isn't
affected (i.e. doesn't even use any of the potentially corrupted bos),
is the idea that the kernel grows the required tracking, or should
userspace always ask the reset state for all contexts and do the math
itself?
There are a couple reasons that all contexts in a share group need
to get the reset notification. Consider an application with two
contexts, A and B. Context A is a worker context that does a bunch
of render-to-texture operations, and context B will eventually
consume those textures. If context A receives a reset, context B,
even if it hasn't done any rendering in five minutes, has lost data.
The kernel should never have any knowledge about GL share groups.
This is where my simplifying assumption (that all contexts in a
share group share an address space and an fd) comes in handy. If
context A queries the reset status from the kernel first, it can
reach over and poke the reset status of context B (in the gl_context
structure). Likewise, if context B queries the kernel first, it can
see that another kernel context in its GL context share group got
reset.
- The above essentially links in with how we blame the guilt and figure
out who's affected. Especially when there's no hw context around, e.g.
on the blitter or bsd rings, or when an object is used by another
process and gets corrupted there. Does the spec make any guarantees for
such a case? Or should we just blame an unknown_reset for all the
contexts that belong to the fd that submitted the bad batch.
That sounds right. If we can't assess innocence or guilt, we should
say guilt is unknown. There are some GL commands that get generate
blits, but I don't think there's anything that can get commands on
the BSD ring. That's just for media, right?
As an idea for the above two issues, what about the kernel also keeps a
per-fd reset statistics, which will also be returned with this ioctl?
We'd then restrict the meaning of the ctx fields to only mean and the
context was actually active. Userspace could then wrap all the per-fd
hang reports into reset_unknown for arb_robustness, but I think this would
be a bit more flexible for other userspace.
Ah, right. So the DDX or libva could detect resets that affect
them. That's reasonable.
struct drm_context_reset_counts {
__u32 ctx_id;
/**
* Index of the most recent reset where this context was
* guilty. Zero if none.
*/
__u32 ctx_guilty;
/**
* Index of the most recent reset where this context was active,
* not guilty. Zero if none.
*/
__u32 ctx_not_guilty;
/**
* Index of the most recent reset where this context was active,
* but guilt was unknown. Zero if none.
*/
__u32 ctx_unknown_guilt;
/**
* Index of the most recent reset where any batchbuffer submitted
* through this fd was guilty. Zero if none.
*/
__u32 fd_guilty;
/**
* Index of the most recent reset where any batchbuffer submitted
* through this fd was not guilty, but affected. Zero if none.
*/
__u32 fd_not_guilty;
/**
* Index of the most recent reset where any batchbuffer submitted
* through this fd was affected, but no guilt for the hang could
* be assigned. Zero if none.
*/
__u32 fd_unknown_guilt;
Since these three fields are per-fd, shouldn't they go in the
proposed drm_reset_counts structure instead? If we do that, it
might be better to split into two queries. One for the per-fd
information, and one for the detailed per-context information. If
we expect the common case to be no-reset, user space could
Oh, I've missed a bit that your ioctl would read out the state for all
contexts on a given fd. My idea was that this is all the data that the
ioctl retuns (and it would only fill out the ctx fields if you spec a
nonzero context). Userspace would then only need to check whether the
context has a new reset number somewhere (= context suffered from a gpu
reset while it was actively used) and then also check whether the fd
suffered from a reset (= something in that gl share group is potentially
corrupted), mapping it to either victim_reset or unknown_reset (depending
upon what exactly the spec wants).
Less complexity in userspace, and imo not too much fuss for the kernel to
do the book-keeping: Instead of only blaming contexts, we also blame
file_privs. That would be a generally useful feature to e.g. cut off
certain fds selectively from the gpu because they hang
[Intel-gfx] [PATCH 1/2] [TRIVIAL] drm/i915/context/: s/CTX/CXT
*sigh* the docs had it spelled wrong, corrected it, and then proceeded to re-do the original error. The original code preserved this history, and this patch attempts to keep in sync with the current docs. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem_context.c | 4 ++-- drivers/gpu/drm/i915/i915_reg.h | 18 +- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 6f5226c..5d0d6ad 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -111,8 +111,8 @@ static int get_context_size(struct drm_device *dev) ret = GEN6_CXT_TOTAL_SIZE(reg) * 64; break; case 7: - reg = I915_READ(GEN7_CTX_SIZE); - ret = GEN7_CTX_TOTAL_SIZE(reg) * 64; + reg = I915_READ(GEN7_CXT_SIZE); + ret = GEN7_CXT_TOTAL_SIZE(reg) * 64; break; default: BUG(); diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 845cbc1..14d33f8 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1482,15 +1482,15 @@ GEN6_CXT_RENDER_SIZE(cxt_reg) + \ GEN6_CXT_EXTENDED_SIZE(cxt_reg) + \ GEN6_CXT_PIPELINE_SIZE(cxt_reg)) -#define GEN7_CTX_SIZE 0x21a8 -#define GEN7_CTX_RENDER_SIZE(ctx_reg) ((ctx_reg 16) 0x3f) -#define GEN7_CTX_EXTENDED_SIZE(ctx_reg)((ctx_reg 9) 0x7f) -#define GEN7_CTX_GT1_SIZE(ctx_reg) ((ctx_reg 6) 0x7) -#define GEN7_CTX_VFSTATE_SIZE(ctx_reg) ((ctx_reg 0) 0x3f) -#define GEN7_CTX_TOTAL_SIZE(ctx_reg) (GEN7_CTX_RENDER_SIZE(ctx_reg) + \ -GEN7_CTX_EXTENDED_SIZE(ctx_reg) + \ -GEN7_CTX_GT1_SIZE(ctx_reg) + \ -GEN7_CTX_VFSTATE_SIZE(ctx_reg)) +#define GEN7_CXT_SIZE 0x21a8 +#define GEN7_CXT_RENDER_SIZE(ctx_reg) ((ctx_reg 16) 0x3f) +#define GEN7_CXT_EXTENDED_SIZE(ctx_reg)((ctx_reg 9) 0x7f) +#define GEN7_CXT_GT1_SIZE(ctx_reg) ((ctx_reg 6) 0x7) +#define GEN7_CXT_VFSTATE_SIZE(ctx_reg) ((ctx_reg 0) 0x3f) +#define GEN7_CXT_TOTAL_SIZE(ctx_reg) (GEN7_CXT_RENDER_SIZE(ctx_reg) + \ +GEN7_CXT_EXTENDED_SIZE(ctx_reg) + \ +GEN7_CXT_GT1_SIZE(ctx_reg) + \ +GEN7_CXT_VFSTATE_SIZE(ctx_reg)) /* * Overlay regs -- 1.7.11.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/context: Add missing IVB context sizes
There were some fields missed. Daniel pointed this out in review, and I know I fixed it, but something happened somehow and some time. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_reg.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 14d33f8..d8af397 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1483,11 +1483,15 @@ GEN6_CXT_EXTENDED_SIZE(cxt_reg) + \ GEN6_CXT_PIPELINE_SIZE(cxt_reg)) #define GEN7_CXT_SIZE 0x21a8 +#define GEN7_CXT_POWER_SIZE(ctx_reg) ((ctx_reg 25) 0x7f) +#define GEN7_CXT_RING_SIZE(ctx_reg)((ctx_reg 22) 0x7) #define GEN7_CXT_RENDER_SIZE(ctx_reg) ((ctx_reg 16) 0x3f) #define GEN7_CXT_EXTENDED_SIZE(ctx_reg)((ctx_reg 9) 0x7f) #define GEN7_CXT_GT1_SIZE(ctx_reg) ((ctx_reg 6) 0x7) #define GEN7_CXT_VFSTATE_SIZE(ctx_reg) ((ctx_reg 0) 0x3f) -#define GEN7_CXT_TOTAL_SIZE(ctx_reg) (GEN7_CXT_RENDER_SIZE(ctx_reg) + \ +#define GEN7_CXT_TOTAL_SIZE(ctx_reg) (GEN7_CXT_POWER_SIZE(ctx_reg) + \ +GEN7_CXT_RING_SIZE(ctx_reg) + \ +GEN7_CXT_RENDER_SIZE(ctx_reg) + \ GEN7_CXT_EXTENDED_SIZE(ctx_reg) + \ GEN7_CXT_GT1_SIZE(ctx_reg) + \ GEN7_CXT_VFSTATE_SIZE(ctx_reg)) -- 1.7.11.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: add register read IOCTL
Ben Widawsky b...@bwidawsk.net writes:
The interface's immediate purpose is to do synchronous timestamp queries
as required by GL_TIMESTAMP. The GPU has a register for reading the
timestamp but because that would normally require root access through
libpciaccess, the IOCTL can provide this service instead.
Currently the implementation whitelists only the render ring timestamp
register, because that is the only thing we need to expose at this time.
v2: make size implicit based on the register offset
Add a generation check
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 8cc7083..fbe7757 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -203,6 +203,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_WAIT0x2c
#define DRM_I915_GEM_CONTEXT_CREATE 0x2d
#define DRM_I915_GEM_CONTEXT_DESTROY 0x2e
+#define DRM_I915_REG_READ0x30
Is 0x2f some other outstanding ioctl?
Other than that,
Reviewed-by: Eric Anholt e...@anholt.net
Note: we have requests both by Arjan and by Valve for the functionality
that this patch will allow.
pgpaSxAYjLYft.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: add register read IOCTL
On Wed, 18 Jul 2012 10:14:46 -0700
Eric Anholt e...@anholt.net wrote:
Ben Widawsky b...@bwidawsk.net writes:
The interface's immediate purpose is to do synchronous timestamp queries
as required by GL_TIMESTAMP. The GPU has a register for reading the
timestamp but because that would normally require root access through
libpciaccess, the IOCTL can provide this service instead.
Currently the implementation whitelists only the render ring timestamp
register, because that is the only thing we need to expose at this time.
v2: make size implicit based on the register offset
Add a generation check
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 8cc7083..fbe7757 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -203,6 +203,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_WAIT 0x2c
#define DRM_I915_GEM_CONTEXT_CREATE0x2d
#define DRM_I915_GEM_CONTEXT_DESTROY 0x2e
+#define DRM_I915_REG_READ 0x30
Is 0x2f some other outstanding ioctl?
I was saving it for some yet to be realized context ioctl. We can use
0x2f, I don't care. Daniel - feel free to change it or not as you
please when/if you suck it in.
Other than that,
Reviewed-by: Eric Anholt e...@anholt.net
Note: we have requests both by Arjan and by Valve for the functionality
that this patch will allow.
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] Support for ns2501-DVO
On Wed, Jul 18, 2012 at 07:22:30PM +0200, Thomas Richter wrote: Hi Daniel, dear intel-drm developers, attached again the ns2501 patch contributed a while ago. Sorry for taking so long to bring this into the correct form, I wasn't in town for the last 3 weeks. So long, Thomas This patch adds support for the ns2501 DVO, found in some older Fujitsu/Siemens Labtops. It is in the state of works for me. Includes now proper DPMS support. Includes switching between resolutions - from 640x480 to 1024x768. Currently assumes that the native display resolution is 1024x768. The ns2501 seems to be rather critical - if the output PLL is not running, the chip doesn't seem to be clocked and then doesn't react on i2c messages. Thus, a quick'n-dirty trick ensures that the DVO is active before submitting any i2c messages to it. This is probably to be reviewed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17902 Signed-off-by: Thomas Richter t...@math.tu-berlin.de Patch queued for -next, with the whitespace fail fixed up - please consult Documentation/CodingStyle and scripts/checkpatch.pl for your next patch submission. I've also looked a bit at your enable_pll quirk and I plan to kill that in some later patches because: - We need to enable pll A unconditionally on i830M, otherwise parts of the chip will power down that shouldn't. For some strange reason we have the wrong entry in our quirk table. - Simply enabling the pll without correct register values will hang the hw. This can happen after e.g. resume. Note that a pretty massive rewrite of the entire i915 modeset code is in the pipeline for 3.7 - consider yourself volunteered to test some neat new code ;-) Cheers, Daniel --- drivers/gpu/drm/i915/Makefile|1 + drivers/gpu/drm/i915/dvo.h |1 + drivers/gpu/drm/i915/dvo_ns2501.c| 566 ++ drivers/gpu/drm/i915/intel_display.c |4 +- drivers/gpu/drm/i915/intel_dvo.c | 10 +- 5 files changed, 580 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/i915/dvo_ns2501.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 2e9268d..8e8e41f 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -39,6 +39,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \ dvo_ivch.o \ dvo_tfp410.o \ dvo_sil164.o \ + dvo_ns2501.o \ i915_gem_dmabuf.o i915-$(CONFIG_COMPAT) += i915_ioc32.o diff --git a/drivers/gpu/drm/i915/dvo.h b/drivers/gpu/drm/i915/dvo.h index 8c2ad01..a2af75c 100644 --- a/drivers/gpu/drm/i915/dvo.h +++ b/drivers/gpu/drm/i915/dvo.h @@ -140,5 +140,6 @@ extern struct intel_dvo_dev_ops ch7xxx_ops; extern struct intel_dvo_dev_ops ivch_ops; extern struct intel_dvo_dev_ops tfp410_ops; extern struct intel_dvo_dev_ops ch7017_ops; +extern struct intel_dvo_dev_ops ns2501_ops; #endif /* _INTEL_DVO_H */ diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c b/drivers/gpu/drm/i915/dvo_ns2501.c new file mode 100644 index 000..1b15a23 --- /dev/null +++ b/drivers/gpu/drm/i915/dvo_ns2501.c @@ -0,0 +1,566 @@ +/** + +Copyright ? 2012 Gilles Dartiguelongue, Thomas Richter + +All Rights Reserved. + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the +Software), to deal in the Software without restriction, including +without limitation the rights to use, copy, modify, merge, publish, +distribute, sub license, and/or sell copies of the Software, and to +permit persons to whom the Software is furnished to do so, subject to +the following conditions: + +The above copyright notice and this permission notice (including the +next paragraph) shall be included in all copies or substantial portions +of the Software. + +THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS +OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, +TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE +SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + +**/ + +#include dvo.h +#include i915_reg.h +#include i915_drv.h + +#define NS2501_VID 0x1305 +#define NS2501_DID 0x6726 + +#define NS2501_VID_LO 0x00 +#define NS2501_VID_HI 0x01 +#define NS2501_DID_LO 0x02 +#define NS2501_DID_HI 0x03 +#define NS2501_REV 0x04 +#define NS2501_RSVD 0x05 +#define NS2501_FREQ_LO 0x06 +#define NS2501_FREQ_HI 0x07 + +#define NS2501_REG8 0x08 +#define NS2501_8_VEN (15) +#define NS2501_8_HEN (14) +#define NS2501_8_DSEL (13) +#define
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
Ok, pushed yet another patch to reimplement those tables within i810. I couldn't spot any more obvious XAA functions called from i810_accel, so hopefully this will be the last iteration! Sigh. Wish you hadn't, the linker behaviour he's seeing is _broken_. Just because we don't know why doesn't make it not a bug. Except it also meant that i810 was indeed broken since it was unusing undefined symbols. No, not the case. Normal ELF behaviour is that external data references are resolved at object load time, but that function references are resolved when they are first called; this is an optimization for app startup time. The former case is not what's going on here, because we're not taking the address of XAAGetPatternROP (a data reference), we're calling it (a function reference): hate:~/driver/xf86-video-intel% git grep XAAGetPatternROP src/legacy/i810/i810_accel.c: (XAAGetPatternROP(rop) 16) | src/legacy/i810/i810_xaa.c: pI810-BR[13] |= XAAGetPatternROP(rop) 16; So those should resolve lazily, which means if you never call them they never _need_ to resolve. And this is how X drivers normally work, notice that libfb isn't loaded _before_ you load your driver but yet the driver loads. And we know the failure case here is not failing to lazily resolve, because if we were hitting _that_ we wouldn't see the error message he's seeing, ld.so would just bitch on stderr and _exit(). The error message he's seeing is dlopen() failing. So this really honestly is a toolchain problem, not a driver problem. Knut, can you send me a copy of your driver binary? I'm really curious to see where that data reference is coming from, assuming BIND_NOW is not what we're seeing. Ok, I built caef63e0268e59e439b030a9a338e81d5cf8e311 using export MYROOT=/home/knut/git/X11-t export PREFIX=$MYROOT/usr export EPREFIX=$PREFIX export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PREFIX/share/pkgconfig export PATH=$PREFIX/bin:$PATH export ACLOCAL=aclocal -I $PREFIX/share/aclocal export LD_LIBRARY_PATH=$PREFIX/lib export PYTHONPATH=$PREFIX/lib/python2.7/site-packages export MAKEFLAGS=-j 15 export GMAKEFLAGS=-j 15 export CC=/opt/icecream/bin/gcc export CXX=/opt/icecream/bin/g++ export CFLAGS=-g2 -O3 --verbose -D MULTITOUCH export CXXFLAGS=-g2 -O3 export LD_PRELOAD=$PREFIX/lib/libmtdev.so util/modular/build.sh -g $PREFIX -o driver/xf86-video-intel --confflags --disable-xaa --localstatedir=$MYROOT/var and got the following log entries: [107706.682] (II) LoadModule: intel [107706.682] (II) Loading /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so [107706.700] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP [107706.700] (II) UnloadModule: intel [107706.700] (II) Unloading intel [107706.700] (EE) Failed to load module intel (loader failed, 7) [107706.700] (EE) No drivers available. [107706.709] Fatal server error: [107706.709] no screens found Bad behaviour restored. I modified my run script to contain LD_DEBUG* export PREFIX=/home/knut/git/X11-t/usr export PATH=$PREFIX/bin:$PATH export LD_LIBRARY_PATH=$PREFIX/lib export LD_PRELOAD=$PREFIX/lib/libmtdev.so export LD_DEBUG=all export LD_DEBUG_OUTPUT=/home/knut/git/X11-t/ld_debug_output /home/knut/startx -- $PREFIX/bin/Xorg and executed it as root. Xorg still fails (nothing else had to be expected). The log is too big for the mailing list, but: knut@golem:~/git/X11-t grep relocation processing ld_debug_output.28936 28936: relocation processing: /lib/libc.so.6 28936: relocation processing: /lib/libgpg-error.so.0 (lazy) 28936: relocation processing: /lib/libpthread.so.0 (lazy) 28936: relocation processing: /lib/librt.so.1 (lazy) 28936: relocation processing: /lib/libm.so.6 (lazy) 28936: relocation processing: /home/knut/git/X11-t/usr/lib/libXdmcp.so.6 (lazy) 28936: relocation processing: /home/knut/git/X11-t/usr/lib/libXau.so.6 (lazy) 28936: relocation processing: /lib/libz.so.1 28936: relocation processing: /home/knut/git/X11-t/usr/lib/libfontenc.so.1 (lazy) 28936: relocation processing: /usr/lib/libfreetype.so.6 (lazy) 28936: relocation processing: /home/knut/git/X11-t/usr/lib/libXfont.so.1 (lazy) 28936: relocation processing: /home/knut/git/X11-t/usr/lib/libpixman-1.so.0 (lazy) 28936: relocation processing: /home/knut/git/X11-t/usr/lib/libdrm.so.2 (lazy) 28936: relocation processing: /home/knut/git/X11-t/usr/lib/libpciaccess.so.0 (lazy) 28936: relocation processing: /lib/libdl.so.2 (lazy) 28936: relocation processing: /lib/libgcrypt.so.11 (lazy) 28936: relocation processing: /lib/libudev.so.0 (lazy) 28936: relocation processing: /home/knut/git/X11-t/usr/lib/libmtdev.so (lazy) 28936: relocation processing:
Re: [Intel-gfx] [PATCH v2] drm/i915: add register read IOCTL
On Wed, Jul 18, 2012 at 10:22:01AM -0700, Ben Widawsky wrote:
On Wed, 18 Jul 2012 10:14:46 -0700
Eric Anholt e...@anholt.net wrote:
Ben Widawsky b...@bwidawsk.net writes:
The interface's immediate purpose is to do synchronous timestamp queries
as required by GL_TIMESTAMP. The GPU has a register for reading the
timestamp but because that would normally require root access through
libpciaccess, the IOCTL can provide this service instead.
Currently the implementation whitelists only the render ring timestamp
register, because that is the only thing we need to expose at this time.
v2: make size implicit based on the register offset
Add a generation check
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 8cc7083..fbe7757 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -203,6 +203,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_WAIT0x2c
#define DRM_I915_GEM_CONTEXT_CREATE 0x2d
#define DRM_I915_GEM_CONTEXT_DESTROY 0x2e
+#define DRM_I915_REG_READ0x30
Is 0x2f some other outstanding ioctl?
I was saving it for some yet to be realized context ioctl. We can use
0x2f, I don't care. Daniel - feel free to change it or not as you
please when/if you suck it in.
Patch queued for -next (with ioctl number 0x31, I've figure when I'll
change it I might as well avoid conflicts with the set_cacheing stuff).
Can you please adjust the i-g-t test and commit that one, too?
Thanks, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Return a mask of the active rings in the high word of busy_ioctl
On Wed, Jul 04, 2012 at 12:42:32PM +0100, Chris Wilson wrote: On Wed, 4 Jul 2012 12:25:08 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: The intention is to help select which engine to use for copies with interoperating clients - such as a GL client making a request to the X server to perform a SwapBuffers, which may require copying from the active GL back buffer to the X front buffer. We choose to report a mask of the active rings to future proof the interface against any changes which may allow for the object to reside upon multiple rings. Queued for -next with the bikeshed applied as discussed on irc, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
On Wed, 2012-07-18 at 20:04 +0200, Knut Petersen wrote: Ok, I built caef63e0268e59e439b030a9a338e81d5cf8e311 using export MYROOT=/home/knut/git/X11-t export PREFIX=$MYROOT/usr export EPREFIX=$PREFIX export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PREFIX/share/pkgconfig export PATH=$PREFIX/bin:$PATH export ACLOCAL=aclocal -I $PREFIX/share/aclocal export LD_LIBRARY_PATH=$PREFIX/lib export PYTHONPATH=$PREFIX/lib/python2.7/site-packages export MAKEFLAGS=-j 15 export GMAKEFLAGS=-j 15 export CC=/opt/icecream/bin/gcc export CXX=/opt/icecream/bin/g++ export CFLAGS=-g2 -O3 --verbose -D MULTITOUCH export CXXFLAGS=-g2 -O3 export LD_PRELOAD=$PREFIX/lib/libmtdev.so util/modular/build.sh -g $PREFIX -o driver/xf86-video-intel --confflags --disable-xaa --localstatedir=$MYROOT/var and got the following log entries: [107706.682] (II) LoadModule: intel [107706.682] (II) Loading /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so [107706.700] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP [107706.700] (II) UnloadModule: intel [107706.700] (II) Unloading intel [107706.700] (EE) Failed to load module intel (loader failed, 7) [107706.700] (EE) No drivers available. [107706.709] Fatal server error: [107706.709] no screens found Bad behaviour restored. So, one difference between the driver you built and the driver in factory: http://download.opensuse.org/pub/opensuse/factory/repo/oss/suse/i586/xf86-video-intel-2.20.0-1.1.i586.rpm Is that yours has this, and theirs doesn't: hate:~% eu-readelf -a intel_drv.so | grep TEXTREL TEXTREL FLAGS TEXTREL This suggests that you managed to build the X driver without -fPIC, and eu-findtextrel(1) agrees. This would cause the problem if text relocations are also not lazy, and I believe that to be the case. [1] To verify this assumption you could just jam -fPIC into CFLAGS and see if the result works, but that's just papering over the bug, not necessarily a fix. I have no idea _how_ you managed to build it that way though. I would start by inspecting config.log and libtool from the build tree, or by pointing $CC at real local gcc instead of icecream. [1] - This, I think, is more artifact of implementation rather than something done of necessity, but since textrels in DSOs are an i686ism as far as Linux is concerned - and generally frowned upon even there - it would be a lot of typing for little benefit. - ajax signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
On Wed, 2012-07-18 at 15:36 +0100, Chris Wilson wrote:
On Wed, 18 Jul 2012 10:29:26 -0400, Adam Jackson a...@redhat.com wrote:
So those should resolve lazily, which means if you never call them they
never _need_ to resolve. And this is how X drivers normally work,
notice that libfb isn't loaded _before_ you load your driver but yet the
driver loads.
They were being used by i810_dri.c, so i810 was busted. It just happened
to be that the first user to spot this was not using i810.
Ennh. PreInit does:
---
if (xf86ReturnOptValBool(pI810-Options, OPTION_NOACCEL, FALSE))
pI810-noAccel = TRUE;
if (!pI810-noAccel) {
if (!xf86LoadSubModule(scrn, xaa)) {
I810FreeRec(scrn);
return FALSE;
}
}
#ifdef HAVE_DRI1
pI810-directRenderingDisabled =
!xf86ReturnOptValBool(pI810-Options, OPTION_DRI, TRUE);
if (!pI810-directRenderingDisabled) {
if (pI810-noAccel) {
xf86DrvMsg(scrn-scrnIndex, X_WARNING, DRI is disabled because it
needs 2D acceleration.\n);
pI810-directRenderingDisabled=TRUE;
} else if (scrn-depth!=16) {
xf86DrvMsg(scrn-scrnIndex, X_WARNING, DRI is disabled because it
runs only at 16-bit depth.\n);
pI810-directRenderingDisabled=TRUE;
}
}
#endif
---
So we default to asking for XAA, and if it doesn't load (because you
built without it) then neither will the driver; conversely, if XAA
loads, DRI's use of XAA symbols would be safe. You'd have to have asked
for Option NoAccel to hit that bug.
It's not clear to me if, subsequent to your change, DRI would work with
NoAccel.
- ajax
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Output problems with displayport-hdmi kable on arrandale based hp elitebook 2540p
Any suggestions how to diagnose this problem further? I really hope I won't need to use VGA forever - the blurry fonts make my eyes bleed ;) - Clemens 2012/7/5 Clemens Eisserer linuxhi...@gmail.com: Hi, I recently bought a HP Elitebook 2540p, which is arrandale based and features a displayport connector (VGA as well). Because quality over VGA is quite bad with my Asus VW266H monitor (1920x1200; vga, hdmi, dvi) I bought a displayport--hdmi cable so I could use the digital output. However, although RANDR seems to report something when connected (in xfce's display dialog I get LGD 12'' (internal) and HDMI 2, the monitor always reports HDMI no signal. Any idea howto diagnose this problem further? I am running Fedora 16 + latest updates (Linux 3.4, intel git). Thank you in advance, Clemens ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
On Wed, 18 Jul 2012 15:47:44 -0400, Adam Jackson a...@redhat.com wrote: So we default to asking for XAA, and if it doesn't load (because you built without it) then neither will the driver; conversely, if XAA loads, DRI's use of XAA symbols would be safe. You'd have to have asked for Option NoAccel to hit that bug. I had not noticed that the code still implied a dependence upon the XAA module. It's not clear to me if, subsequent to your change, DRI would work with NoAccel. It does. The mapping of the ring and control registers was already managed outside of the XAA specific routines, so enabling the blit function without the XAA infrastructure is fine. Tested insofar as running glxgears on a remote i815 with XAA exorcised. Not totally convinced I've verified all the necessary paths, but it loads and seems to run. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Output problems with displayport-hdmi kable on arrandale based hp elitebook 2540p
On Thu, 19 Jul 2012 00:16:59 +0200, Clemens Eisserer linuxhi...@gmail.com wrote: Any suggestions how to diagnose this problem further? I really hope I won't need to use VGA forever - the blurry fonts make my eyes bleed ;) Do please open a bug on fd.o so that we can at least keep reminding ourselves of the issue. Unfortunately it sounds like yet another example where DP-dongle is broken. Attaching a drm.debug=0x6 dmesg and being prepared to run random kernel trees is a minimum. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Output problems with displayport-hdmi kable on arrandale based hp elitebook 2540p
On Thu, 19 Jul 2012 00:16:59 +0200, Clemens Eisserer linuxhi...@gmail.com wrote: I really hope I won't need to use VGA forever - the blurry fonts make my eyes bleed ;) Yeah, just be aware that DP to HDMI/DVI isn't really a 'dongle' in the usual sense, the whole internal hardware is running in HDMI mode, just sending the data over the DP wires. The cable then just converts the signal levels. So, our driver sees a regular HDMI output, which is vastly simpler than the DP to VGA dongles which look like DP to the computer and VGA to the monitor. I've tried a bunch of monitors using this mode and it's always worked just fine; you might try a different cable, or test with a different monitor if you can find one. -- keith.pack...@intel.com pgpZLuYTlMcBT.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] GPU reset notification interface
On Wed, 18 Jul 2012 18:55:08 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Jul 18, 2012 at 09:23:46AM -0700, Ian Romanick wrote:
On 07/18/2012 02:20 AM, Daniel Vetter wrote:
- The all contexts in a share group need to receive a reset notification
wording is irking me a bit because we currently only track all the
actively used things. So if another context in that share group isn't
affected (i.e. doesn't even use any of the potentially corrupted bos),
is the idea that the kernel grows the required tracking, or should
userspace always ask the reset state for all contexts and do the math
itself?
There are a couple reasons that all contexts in a share group need
to get the reset notification. Consider an application with two
contexts, A and B. Context A is a worker context that does a bunch
of render-to-texture operations, and context B will eventually
consume those textures. If context A receives a reset, context B,
even if it hasn't done any rendering in five minutes, has lost data.
The kernel should never have any knowledge about GL share groups.
This is where my simplifying assumption (that all contexts in a
share group share an address space and an fd) comes in handy. If
context A queries the reset status from the kernel first, it can
reach over and poke the reset status of context B (in the gl_context
structure). Likewise, if context B queries the kernel first, it can
see that another kernel context in its GL context share group got
reset.
- The above essentially links in with how we blame the guilt and figure
out who's affected. Especially when there's no hw context around, e.g.
on the blitter or bsd rings, or when an object is used by another
process and gets corrupted there. Does the spec make any guarantees for
such a case? Or should we just blame an unknown_reset for all the
contexts that belong to the fd that submitted the bad batch.
That sounds right. If we can't assess innocence or guilt, we should
say guilt is unknown. There are some GL commands that get generate
blits, but I don't think there's anything that can get commands on
the BSD ring. That's just for media, right?
As an idea for the above two issues, what about the kernel also keeps a
per-fd reset statistics, which will also be returned with this ioctl?
We'd then restrict the meaning of the ctx fields to only mean and the
context was actually active. Userspace could then wrap all the per-fd
hang reports into reset_unknown for arb_robustness, but I think this would
be a bit more flexible for other userspace.
Ah, right. So the DDX or libva could detect resets that affect
them. That's reasonable.
struct drm_context_reset_counts {
__u32 ctx_id;
/**
* Index of the most recent reset where this context was
* guilty. Zero if none.
*/
__u32 ctx_guilty;
/**
* Index of the most recent reset where this context was active,
* not guilty. Zero if none.
*/
__u32 ctx_not_guilty;
/**
* Index of the most recent reset where this context was active,
* but guilt was unknown. Zero if none.
*/
__u32 ctx_unknown_guilt;
/**
* Index of the most recent reset where any batchbuffer submitted
* through this fd was guilty. Zero if none.
*/
__u32 fd_guilty;
/**
* Index of the most recent reset where any batchbuffer submitted
* through this fd was not guilty, but affected. Zero if none.
*/
__u32 fd_not_guilty;
/**
* Index of the most recent reset where any batchbuffer submitted
* through this fd was affected, but no guilt for the hang could
* be assigned. Zero if none.
*/
__u32 fd_unknown_guilt;
Since these three fields are per-fd, shouldn't they go in the
proposed drm_reset_counts structure instead? If we do that, it
might be better to split into two queries. One for the per-fd
information, and one for the detailed per-context information. If
we expect the common case to be no-reset, user space could
Oh, I've missed a bit that your ioctl would read out the state for all
contexts on a given fd. My idea was that this is all the data that the
ioctl retuns (and it would only fill out the ctx fields if you spec a
nonzero context). Userspace would then only need to check whether the
context has a new reset number somewhere (= context suffered from a gpu
reset while it was actively used) and then also check whether the fd
suffered from a reset (= something in that gl share group is potentially
corrupted), mapping it to either victim_reset or unknown_reset (depending
upon what exactly the spec wants).
Less complexity in userspace, and imo not too much fuss for the kernel to
do the book-keeping: Instead of only blaming contexts,
