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

Reply via email to