[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    Re: xserver: Branch 'master' - 12 commits
From:       Benjamin Herrenschmidt <benh () kernel ! crashing ! org>
Date:       2006-09-29 0:30:27
Message-ID: 1159489827.9974.102.camel () localhost ! localdomain
[Download RAW message or body]


> Note that:
>  a) MEMCPY_WRAPPED expands to a simple call to memcpy in libfb, so only
>     libwfb uses this loop.
>  b) fb24_32.c, which contains the comment you referenced, doesn't use
>     MEMCPY_WRAPPED, so it will continue to do aligned CARD32 accesses.
>  c) In libwfb, each of those accesses calls through a function pointer,
>     which sucks way more than aligned/unaligned accesses (I assume.  I
>     don't know much about ARM).

On some platforms, unaligned accesses will trap, and have to be emulated
by the kernel, thus are way more expensive than a function call. Not
sure about ARM, but some embedded ppc's I think will be unhappy here.
Function pointer calls suck too, and probably more on fast archs, but
still...

> It's theoretically possible that some hardware could have a really funny
> tile pattern where doing memcpys from linear to tiled or vice-versa can't
> be done in chunks of four bytes.  In practice, I don't know if that will
> ever be the case.  If you really feel strongly about it, would something
> like this be better?

Can't you rely on memcpy being smart enough to do the right thing ?
Glibc memcpy will probably know the platform, do unaligned if it works
fine and avoid it if not on a given platform, and might even be
optimized for a specific CPU.

Ben.



[prev in list] [next in list] [prev in thread] [next in thread]