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

Reply via email to