Keith Packard wrote: >I will not be able to comment on unreleased hardware designs and how >they affect the DRM design. Suffice it to say that this granularity of >signalling seems unnecessary to me; a single flush operation that was >signalled at the end of the sequence to free all of these buffers seems >more than adequate. > > > A quite recent version of Poulsbo DRM exposing this use of fence_types has been released by Intel and is available at
https://launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/2.6.22-14.38 While fence_types are not used for flushing here, exposing them is crucial for efficient memory usage. Remember that binning hardware will generally try to submit a full scene of vertices at a time. Holding on to these vertex buffers until the GPU is completely done with the scene is *not* a wise thing to do. >I think the biggest issue right now is that buffers must be tied to >flushing fences every time they are used -- otherwise, they will never >be known to have been flushed. > > I also would like to stress that waiting for a fence will never initiate a flush if there is an already pending or executed flush that would flush or has already flushed the command sequence it represents. /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
