Thomas Hellström wrote:
> Eric Anholt wrote:
>
>>
>> Going from CACHED_MAPPED back to uncached even with buffer reuse is a
>> 22% performance drop (but at least it's not the 79% hit to the face you
>> get without buffer reuse).
>>
>>   
> Hmm, this sounds odd. That simply means you must still be doing a lot 
> of buffer binding / unbinding? Relocations using master drm will also 
> be slow of course.
Oh, and of course one must make sure that display list VBOs don't end up 
in WC memory if we're doing any software vertex processing. Otherwise 
apps like gears will read vertex data from WC memory which will kill 
performance. That means adjusting intel_buffer_objects.c to make sure 
VBOs end up CACHED.
>> So, I want DRM_BO_FLAG_CACHED_MAPPED to be the default for our DRM when
>> you don't ask for cached buffers, determined by the driver flagging it
>> as doable on this chipset.
>>   
> I see two problems with this: One is cosmetic in that 
> DRM_BO_FLAG_CACHED_MAPPED doesn't have the same semantics as 
> !DRM_BO_FLAG_CACHED. You can't use it for user-space buffer pools.
... And thinking more about this, you can't really use it for scanout 
buffers either, unless you want to clflush() twice and chipset flush for 
each write operation.
>
> /Thomas
>
>
/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

Reply via email to