M Joonas Pihlaja <[email protected]> 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 _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
