Keith Whitwell wrote: > 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... > > Doesn't Kristian changes to DRI interface (DRI2) already allow to clients to not care about front buffer. I mean if they all got private back buffer then they render into it. But i might have misunderstood this.
Cheers, Jerome Glisse ------------------------------------------------------------------------- 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
