Allen Akin wrote:
> On Fri, Jun 12, 2009 at 10:25:42AM +1000, Dave Airlie wrote:
> | On Fri, Jun 12, 2009 at 10:01 AM, Allen Akin<[email protected]> wrote:
> | > On the other hand, if there's no mechanism for implicitly flushing the
> | > GL command stream on window teardown, then whatever problems this error
> | > is designed to address can happen every time a window is closed. I
> | > would expect to find something in the spec that says "You must execute
> | > (SwapBuffers|Flush|Finish...) before destroying a bound window or
> | > such-and-such bad things can happen." Trivial test programs would have
> | > been failing since day one.
> |
> | Well usually when the window is torndown, we exit straight away afterwards,
> | normally you don't keep going...
>
> I don't think you have to keep going -- all you have to do is destroy
> the window when there are still GL commands that haven't been flushed.
> It looks like the same (or very similar) problem to me; what do you do
> with those commands that have been queued up for a now-nonexistent
> window?
>
> | ... however the glean test case does another
> | test which opens a new window and rendering context and calls MakeCurrent
> | on it, thereby triggering the above failure case. esp after it has
> | done rendering
> | on the previous context and then blown away the window without flushing or
> | swapbuffers.
>
> I didn't trace the test, so I'm not fully confident about this, but it
> looks to me like this is the sequence of commands:
>
> Create window.
> Create rendering contexts.
> Make an RC current.
> Clear the buffer.
> Query the clear color.
> ReadPixels() to get the contents of the buffer.
> <repeat>
> Destroy rendering contexts.
> (one RC is still current, so its destruction is postponed)
> Destroy window.
> ...
> A subsequent test does a MakeCurrent, which triggers the error.
>
> The ReadPixels() does an implicit flush. Since it's the last operation
> before the MakeCurrent, and it's synchronous, there should be no other
> commands remaining in the GL stream at the time of the MakeCurrent. If
> that's correct, it explains why this problem has never been detected
> before, and it suggests that there might still be an implementation bug
> to be tracked down. What's left in the queue, or is it marked nonempty
> even though it's really empty?
>
> I'm persuaded that the test should be changed, though. It's not
> reasonable to depend on the flushing behavior of ReadPixels to meet the
> requirements of the spec, since a minor modification of the test could
> cause things to start failing mysteriously.
>
> | > What happens when one X client destroys a window that another one is
> | > using for GL rendering? The destruction of the window has to be
> | > postponed until it's no longer bound to an RC, or the GL command queue
> | > has to be redirected to a black hole, or GL rendering has to be
> | > terminated by error somehow. Or something else.
> |
> | If the window is destroyed the app normally gets a SIGPIPE and dies soon
> | after.
>
> Really? That surprises me. For normal X apps, I would think it would
> just get an error delivered via the X protocol the next time it attempts
> to use the window ID. The GL case seems messier.
I hacked mesa/progs/xdemos/glxglears.c to destroy its window after 200
frames are rendered.
1. With sw rendering, we exit with an X protocol error inside
glXSwapBuffers when we call XPutImage():
X Error of failed request: BadDrawable (invalid Pixmap or Window
parameter)
Major opcode of failed request: 72 (X_PutImage)
Resource id in failed request: 0x4800002
Serial number of failed request: 824
Current serial number in output stream: 826
2. With the i965 DRI driver we again exit from an X protocol error
when trying to get the drawable info:
X Error of failed request: BadDrawable (invalid Pixmap or Window
parameter)
Major opcode of failed request: 135 (XFree86-DRI)
Minor opcode of failed request: 9 ()
Resource id in failed request: 0x3800002
Serial number of failed request: 644
Current serial number in output stream: 644
#0 _XError (dpy=0x22cd010, rep=0x7fff38bf88a0) at XlibInt.c:2895
#1 0x00007fe33062cf30 in _XReply (dpy=0x22cd010, rep=0x7fff38bf88a0,
extra=1, discard=0) at XlibInt.c:1857
#2 0x00007fe330996e80 in XF86DRIGetDrawableInfo (dpy=0x22cd010,
screen=0, drawable=58720258, index=0x22d453c, stamp=0x22d4548,
X=0x22d454c, Y=0x22d4550, W=0x22d4554, H=0x22d4558,
numClipRects=0x22d455c, pClipRects=0x22d4560, backX=0x22d4568,
backY=0x22d456c,
numBackClipRects=0x22d4574, pBackClipRects=0x22d4578) at
XF86dri.c:495
#3 0x00007fe3309949db in __glXDRIGetDrawableInfo (drawable=0x22d4520,
index=0x22d453c, stamp=0x22d4548, X=0x22d454c, Y=0x22d4550,
W=0x22d4554, H=0x22d4558, numClipRects=0x22d455c,
pClipRects=0x22d4560, backX=0x22d4568, backY=0x22d456c,
numBackClipRects=0x22d4574,
pBackClipRects=0x22d4578, loaderPrivate=0x22d44e0) at dri_glx.c:250
#4 0x00007fe32fa2bca0 in __driUtilUpdateDrawableInfo (pdp=0x22d4520)
at ../common/dri_util.c:249
#5 0x00007fe32fa3ad0a in intelContendedLock (intel=0x22e1940,
flags=0) at intel_context.c:989
#6 0x00007fe32fa3b0b2 in LOCK_HARDWARE (intel=0x22e1940) at
intel_context.c:1069
#7 0x00007fe32fa7e439 in brw_try_draw_prims (ctx=0x22e1940,
arrays=0x2327878, prim=0x7fff38bf8c30, nr_prims=1, ib=0x0, min_index=0,
max_index=3) at brw_draw.c:352
#8 0x00007fe32fa7e773 in brw_draw_prims (ctx=0x22e1940,
arrays=0x2327878, prim=0x7fff38bf8c30, nr_prims=1, ib=0x0, min_index=0,
max_index=3) at brw_draw.c:481
#9 0x00007fe32fb916d8 in vbo_exec_DrawArrays (mode=6, start=0,
count=4) at vbo/vbo_exec_array.c:502
That's using DRI1.
3. With NVIDIA's driver the window still appears on screen (and
rendering continues) even after XDestroyWindow() is called. But if
you try to move/resize the window it then disappears, but glxgears
seems to keep on running. It's interesting that the event loop's
XPending() and XNextEvent() calls don't generate an X protocol error.
Perhaps the server is refcounting the window and as long as the GLX
context is bound to the window, it isn't really destroyed.
-Brian
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
