From: Leif D. <lde...@re...> - 2003-02-04 22:31:36
|
On Tue, 4 Feb 2003, Keith Whitwell wrote: > Leif Delgass wrote: > > I investigated why radeonDestroyContext wasn't being called for many of > > 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. > > The kernel modules have hooks for cleaning things up on client exit -- the > 'release' method of the file descriptor. Ah, right. That's the DRIVER_(PRE)RELEASE macro, right? I had played around with having contexts release texture regions (mark them as unused) in the global heap when they destroy/swap-out textures or the context is going away, but there was always the problem of what to do if the context was killed and didn't clean up. The problem I was trying to solve was a situation where we'd switch from the local fb texture heap to the agp heap for texture allocations even though there were unused regions in local memory. I'll have to take a look at texmem more closely to see if that's still something that can happen. Then again, maybe it would be better to focus on the forthcoming 'Return of Son of Texmem' branch changes. :) > > 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. ;) > > 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. 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? -- Leif Delgass http://www.retinalburn.net |