On Mon, 2008-05-19 at 20:22 +0200, Thomas Hellström wrote: > I think the point here is when the buffer in 1) is mapped write-combined > which IMHO is the obvious approach, > the caches aren't affected at all.
write-combining only wins if you manage to get writes to the same cache line to line up appropriately. Doing significant computation between writes to the WC region means failing to meet the necessary conditions, so the WC writes end up trickling out slowly. > In 2) you have two opportunities to completely fill the cache with data > that shouldn't need to be reused. With cache-aware copy code you can > reduce the impact of one of those opportunities. The allocator should be re-using recently freed pages for other activity, so your cache-loaded pages will not go to waste, even if all you did was fill them with data and copy them to the graphics object. So, it turns out the 'malloc, fill, copy, free' cycle is actually fairly good from a cache perspective. And, the gem benchmarks bear this out with better-than-classic bandwidth from CPU to GPU for raw vertices. We might do better by using WC pages on the backend, rather than using clflush, but not a lot. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
