Keith Whitwell wrote: > Jerome Glisse wrote: >> 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... >>> While this is probably a good idea, the discussion is really whether we should use a more general drmBOSetStatus() or a subset drmBOSetPin(). With drmBOSetStatus() we can easily implement a workaround for the (perhaps soon disappearing) fragmentation problem, but there are a couple of other uses as well.
/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
