[Pixman] disable cache prefetch on ATOM can improve the gtkperf performance

[Soeren Sandmann]

M Joonas Pihlaja <jpihlaja at cc.helsinki.fi> writes:

> With a lower threshold for cairo-perf-diff you'll see that nearly 
> across the board there's a small slowdown from using prefetching.  On 
> the whole my experience with prefetching for graphics is that it's not 
> been very useful to do manually mostly since the streaming access 
> logic on most memory controllers seems to work pretty well.  I've 
> never seen this big of a difference from actively using prefetching, 
> but then again this is the first time I've run tests on real app code 
> when looking at it.

Thanks for benchmarking. All data so far indicates that it's somewhere
between 'small slowdown' and 'no real effect'. Unless Andre can come
up with benchmark results that actually show an improvement from
prefetching, it really does look like just turning it off is the best
option.

> In my experience a far bigger impact can be seen from the kind of 
> memory move instruction you use to access the data, what caches the 
> data turns out to be in, and how many streams you're trying to access 
> concurrently.  For instance using a non-temporal move in the wrong 
> place can really wreak havoc with performance, so it's a bad idea to 
> use in generic code paths IMO.

Yeah, non-temporal instructions may kick out the cache line in
question, even if it is already in cache. I don't think we use them at
the moment.

The one case in pixman where I think it could make sense is when we
are doing solid fill to an image that is larger than the last level
cache. In that case the cache line is doomed anyway, so we might as
well take the faster non-temporal write.


Soren