On Tue, Oct 1, 2013 at 2:27 AM, Ian Romanick <i...@freedesktop.org> wrote: > On 09/27/2013 04:46 PM, Kenneth Graunke wrote: >> This was only used for uploading batchbuffer data, and only on 32-bit >> systems. If this is actually useful, we might want to use it more >> widely. But more than likely, it isn't. > > This probably is still useful, alas. The glibc memcpy wants to do an > Atom-friendly backwards walk of the addresses.
Erm... just curious: Are you sure this is done for Atom ? Originally such copy-from-highest-to-lowest-address copying is (should be: "was") done to enable overlapping copies... but at least POSIX mandates that |memcpy()| is not required to support overlapping copies and users should use |memmove()| instead in such cases (for example Solaris uses the POSIX interpretation in this case... and AFAIK Apple OSX even hits you with an |abort()| if you attempt an overlapping copy with |memcpy()| (or |strcpy()|) (and AFAIK "valgrind" will complain about such abuse of |memcpy()|/|strcpy()|/|stpcpy()|, too)). > For some kinds of > mappings (uncached?), this breaks write combining and ruins performance. That more or less breaks performance _everywhere_ because automatic prefetch obtains the next cache line and not the previous one. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
