Re: recent fixes in devel tree

Dan Malek [off-list ref] writes:

Holger Bettag wrote:

quoted

P.S.: BTW, is there a general consensus wether or not AltiVec
      enhancements in the kernel would be a good thing.....

What kind of enhancements?  I do a fair amount of audio/video
processing on my G4 with the current gcc/Altivec tools.  I found only
one minor bug in the exception handler that I fixed a while back.

We have been discussing some of the vector load/store/touch as both
enhancements to the kernel and glibc.  It is a little more challenging
in the kernel because we would have to then keep some of the vector
context around for the kernel, but in a very constrained case we could
probably get some speed ups with that.

I know too little about the kernel to suggest specific tunings. I
thought along the lines you mention, inserting a 'data stream touch'
here and there for improved bus utilization, occasional use of AltiVec
code where it tends to speed things up a lot, like doing checksums for
software RAIDs or other fast I/O channels. Maybe 'generic' video
acceleration of the OpenFirmware framebuffer device, or something like
that. (Maybe I/O en-/decryption, if such functionality ever ends up in
the kernel.)

I mainly wanted to know wether there are efforts underway to make the
use of AltiVec in the kernel a no-brainer (like: "just pass -fvec and
use the AltiVec-'macros'!"), or wether it will be only for wizards at
the bleeding edge.

  Holger

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Holger Bettag wrote:

I know too little about the kernel to suggest specific tunings.

Suggestions always make people think......

.... I
thought along the lines you mention, inserting a 'data stream touch'
here and there for improved bus utilization, occasional use of AltiVec
code where it tends to speed things up a lot,

The data stream touch is maybe useful in some very specific places.
I have written user level performance tests to see where it is
beneficial, and you have to be careful.  Yes, it can speed things
up when all of the bits line up just right, but you can also screw up
with it as well :-).  Oh, I use it, but it isn't a quick and generic
solution.

I mainly wanted to know wether there are efforts underway...
.... or wether it will be only for wizards at
the bleeding edge.

Oh, there are a few.  Bleeding edge is a good description, but
wizard is more like 'wizzing' (perhaps into the wind :-) in some
cases....

I'm working on several user applications (audio, video, MPEG, etc)
that utilize Altivec, so I'm getting a pretty good idea how to tune
data streams and caches.  Some of this will probably find it's way
into the C library (and has already in some of the MPEG libraries)
for performance enhancement.  The challenge in the kernel is making
the Altivec context available for the kernel.  The Altivec is faster,
but it comes at a higher set-up cost that you also have to consider.
We'll get some in there.  It is definitely hardware that will get
utilized more and more.


	-- Dan

--

	I like MMUs because I don't have a real life.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/