On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote: > It depends on the hardware. In the second approach the driver has no > opportunity to do something "smart" if the copy path isn't the fast > path. Applications are being tuned more for the hardware where the copy > path isn't the fast path.
It really only depends on the CPU and bus architecture; the GPU architecture is not relevant here. The cost is getting data from the CPU into the GPU cache coherence domain, currently that involves actually writing the data from the CPU over some kind of bus to physical memory. > The obvious overhead I was referring to is the extra malloc / free. > That's why I went on to say "So, now I have to go back and spend time > caching the buffer allocations and doing other things to make it fast." > ~ In that context, "I" is idr as an app developer. :) You'd be wrong then -- the cost of the malloc/write/copy/free is cheaper than the cost of map/write/unmap. > One problem that we have here is that none of the benchmarks currently > being used hit any of these paths. OpenArena, Enemy Territory (I assume > this is the older Quake 3 engine game), and gears don't use MapBuffer at > all. Unfortunately, any apps that would hit these paths are so > fill-rate bound on i965 that they're useless for measuring CPU overhead. The only place we see significant map/write/unmap vs malloc/write/copy/free is with batch buffers, and so far the measurements that I've taken which appear to show a benefit haven't been reproduced by others... -- [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
