Keith Packard wrote: > On Wed, 2008-05-14 at 21:41 +0200, Thomas Hellström wrote: > > >> As you've previously mentioned, this requires caching policy changes and >> it needs to be used with some care. >> > > I did't need that in my drivers as GEM handles the WB -> GPU object > transfer already. > > Object mapping is really the least important part of the system; it > should only be necessary when your GPU is deficient, or your API so > broken as to require this inefficient mechanism. I suspect we'll be > tracking 965 performance as we work to eliminate mapping, we should see > a steady increase until we're no longer mapping anything that the GPU > uses into the application's address space. > > Static wc-d maps into fairly static objects like scanout buffers or buffer pools are not inefficient. They provide the by far highest throughput for writing (even beats cache-coherent). But they may take some time to set up or tear down, which means you should avoid that as much as possible. For things like scanout buffers or video buffers you should really use such mappings, otherwise you lose big.
The current implementation of GEM that doesn't allow overloading of the core GEM functions blocked the possibility to set up such mappings. This is about to change, and I'm happy with that. /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
