[Mesa-dev] [PATCH 28/29] i965: Drop random 32-bit assembly implementation of memcpy().

[Roland Mainz]

On Tue, Oct 1, 2013 at 2:27 AM, Ian Romanick <idr at 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.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)