On 09/30/2013 05:47 PM, Roland Mainz wrote: > 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)).
I was pretty sure it was Atom... though looking at the glibc source, the backward memcpy is only used on Core i3, i5, and i7 unless USE_AS_MEMMOVE is defined. Hmm... >> 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. Except your out-of-order CPU is really smart, and, IIRC, that makes it usually not break. I think. > ---- > > Bye, > Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
