Ian Romanick wrote: >>>A lot of this stuff is inherently device independent with some device >>>dependent "direction" (i.e., *ChooseTextureFormat), but it hasn't been >>>implemented that way. As a reference point, my previous work removed >>>somewhere around 450 lines of code from the MGA driver (~5%). The gains in >>>the Radeon weren't quite as significant (there was no radeon_texcnv.c to get >>>rid of). This just feels like a win-win to me. :) >>> >>>Having all of it in the kernel will make it easier to implement other >>>off-screen buffers that can't be stolen (i.e., pbuffers, dynamically >>>allocated back/depth buffer, etc.). >> >>I take it you don't really mean "all" of it, ie. not the texture conversion >>stuff you mention in the preceding paragraph. > > > Right. I wanted to move the code that actually does the allocation, > deallocation, and stealing into the kernel. The only problem that I saw was > in notifying applications that their memory had been stolen. Sending a > signal seemed like it would work, but that also felt like a very ugly > solution.
Two potential solutions that I can think of: 1) Track what's valid and not in shared memory and have the client check before using it. Access may need to be protected with a semaphore or DRM lock. 2) This one's a little wild just for what you want, but it's something Workstation Vendors have done in the past to virtualize limited resources...When stealing memory, setup the page tables to generate a page fault if it's accessed. Then have the handler steal memory from another application and replace memory for faulting application. -- /\ Jens Owen / \/\ _ [EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel