Hi.
Eric Anholt wrote:

>On Thu, 2007-10-18 at 07:55 +0800, Keith Packard wrote:
>  
>
>>On Wed, 2007-10-17 at 16:40 -0700, Eric Anholt wrote:
>>
>>    
>>
>>>Turn off CRTCs
>>>Unpin old framebuffer
>>>Allocate new framebuffer
>>>Copy from old to new
>>>      
>>>
>>We needn't copy on resize, leaving us with allocate new, unpin old, pin
>>new, free old. Seems like this would avoid some of the worst issues.
>>    
>>
>
>True.  The issue would still exist if you happened to accelerated clear
>your new frontbuffer before pinning it, which we could avoid in the
>driver.  And even if you do everything right, in the case of expanding
>your framebuffer I don't think there would be any guarantee of getting
>put at the least-fragmenting place to have a pinned buffer.
>
>I think the solution to that that I suggested is reasonable and deals
>with thomas's and our fragmentation concerns (don't use validate, just
>find the space we would most like to be at not containing pinned
>objects, evict whoever's there, and pin it).
>
>  
>
Hmm, I missed this message somehow.

Anyway, this scheme seems to be the best solution to avoid pinned buffer 
fragmentation. However it's not straightforward to implement with the 
current code. One way would be to decide on a target memory region, do a 
full memory region clean on that one (keeping only pinned buffers) and 
then let the default logic handle the rest.

>Also, while I'm not a fan of the vague name of drmBOSetStatus, it sounds
>like it would be usable to do the map hinting I suggested.
>
>  
>
It would. If we're going to change the name we'd better do it now. Any 
suggestions?

/Thomas





-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to