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<a...@pobox.com> 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel