On Tue, 4 Feb 2003, Keith Whitwell wrote:
> > Yes, I ran into this too when the DMA buffer is flushed in
> > radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE
> > macro in the lock function, so that makes sense. Where is the drawable
> > destroyed?
>
> That's the one. I haven't looked at it deeply yet (which app did you see this
> with?). I assume it gets destroyed in a previous call to XDestroyWindow(),
> which the dri doesn't know anything about.
>
> Keith
glutDestroyWindow does indeed call XDestroyWindow before
glXDestroyContext. I noticed that glxgears does it the other way around,
and doesn't produce the X error.
As a workaround, I tried adding this to radeonGetLock and I didn't get any
errors:
if ( dPriv->refcount > 0 )
DRI_VALIDATE_DRAWABLE_INFO( sPriv, dPriv );
Maybe we could just return at that point if refcount < 1, rather than
going on to deal with cliprects and texture aging. Is that needed before
the command buffer gets flushed?
Do you think this could be a valid fix? I'm not sure exactly what
refcount is counting, but from my quick test with glxgears and texobj it
appears to be 1 when the window still exists and zero when it doesn't.
However, I don't know if we can rely on this being up to date.
Intersting also is that glut doesn't seem to call XCloseDisplay, as
radeonDestroyScreen doesn't get called. glxgears calls XCloseDisplay and
that seems to call radeonDestroyScreen (it doesn't happen in
XDestroyWindow).
--
Leif Delgass
http://www.retinalburn.net
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
