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() /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 > ------------------------------------------------------------------------- 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
