Thomas Hellström wrote: > Hi, Eric. > > Eric Anholt wrote: ...
>> Can you clarify the operation being done where you move scanout buffers >> before unpinning them? That seems contradictory to me -- how are you >> scanning out while the object is being moved, and how are you >> considering it pinned during that time? >> >> > Actually it's very similar to Dave's issue, and the buffers aren't > pinned when they are thrown out. What we'd want to do is the following: > > 1) Turn of Crtcs. > 2) Unpin the buffer > 3) Destroy the buffer, leaving it's memory area free. > 4) Create and pin new buffer (skipping the copy) > 5) Turn on Crtcs. > > However, with DRI clients operating, 3) will fail. As they may maintain > a reference on the front buffer, the old buffer won't immediately get > destroyed and it's aperture / VRAM memory area isn't freed up, unless it > gets evicted by a new allocation. Is there really a long-term need for DRI clients to maintain a reference to the front buffer? We're moving away from this in lot of ways and if it is a benefit to the TTM work, we could look at severing that tie sooner rather than later... > This will in many cases lead to > fragmentation where it is really possible to avoid it. The best thing we > can do at 3) is to move it out, and then unreference it. When the DRI > client recognizes through the SAREA that there's a new front buffer, it > will immediately release its reference on the old one, but basically, > the old front buffer may be hanging around for quite some time (paused > dri clients...) and we don't want it to be present in the aperture, even > if it's evictable. This won't stop fragmentation in all cases, but will > certainly reduce it. At very least, current DRI/ttm clients could be modified to only use the frontbuffer reference in locked regions, and to have some way of getting the correct handle for the current frontbuffer at that point. Longer term, it's easy to imagine DRI clients not touching the front buffer independently and not requiring a reference to that buffer... Keith ------------------------------------------------------------------------- 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
