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
