On Tue, May 20, 2008 at 1:29 PM, Thomas Hellström <[EMAIL PROTECTED]> wrote: > Keith Packard wrote: >> On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote: >> >>> 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... >> > > We could certainly use "texdown" to test this out, if the GEM i915 > driver implemented a pwrite-enabled > struct dd_function_table::TextureMemCpy()
Double-copy texture uploads have been 'tested' in the past -- and their poor performance was one of the motivating factors for creating a single-copy scheme. The double-copy upload path isn't *that* bad, as long as the entire texture fits into cache... As soon as it exceeds the cache dimensions, it falls off a cliff. FWIW, Intel are making some cpus with pretty small caches these days, and teaming them up with i945 gpus, so this isn't completely theoretical. Keith ------------------------------------------------------------------------- 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
