Leif Delgass wrote:
I investigated why radeonDestroyContext wasn't being called for many ofThe kernel modules have hooks for cleaning things up on client exit -- the 'release' method of the file descriptor.
the Mesa demos. It turns out that only a few of the demos actually
destroy the window and/or context before exit()-ing on a key press event. So if a glut app doesn't call glutDestroyWindow() or a glx app doesn't
call glXDestroyContext and XDestroyWindow/XCloseDisplay then the Mesa
client driver's DestroyContext/DestroyScreen never get called. This is
also the case if the app is killed by a signal.
So I guess we can't assume that these functions will be called, meaning
that trying to clean up state in the SAREA (e.g. global texture regions) or flushing remaining buffers from those functions can't necessarily be
relied on.
Yes, I've got a report of a similar problem where the driver tries to grab a lock after destroying the drawable. Strictly this is allowable, but our lock-grabbing function does some stuff that depends on having a drawable handy.Also, it appears that the DRM lock is _not_ held on entering the driver's DestroyContext. I don't think this is really a problem for the current drivers, but some of my assumptions were wrong so I thought I'd point this out in case anyone else was operating under the same assumptions. ;)
Keith
-------------------------------------------------------
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
