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). 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. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
