[PD-dev] [GEM] Further CVS changes

[Mathieu Bouchard]

On Thu, 30 Jan 2003, guenter geiger wrote:

Hi. I thought it would be interesting to share our experiences on that
topic...

> At least we should get rid of float pixel processing on all platforms.

I am quite close to do the opposite: I started with support for only
one (albeit big) integer type, and I now support three integer types, and
I'm going to add float32 support eventually. The main things that are
blocking me are that several int operators (%,&,|,^) are not available for
floats in C, and have no obvious mapping to a simple expression (i expect
those operations to be homomorphic, so that most patches that work in
int16 get to work in float32 at once...)

> I have also done experiments with MMX (which, I have to
> admit, did not give the results I had hoped for, but maybe just
> because I did not really know what I was doing ).

I have added MMX code to my software; the asm code is generated with a
script. The results I get with int32 are slightly slower than GCC's
non-MMX output, and I'm doing pretty close to my best. However with int16
and uint8 the MMX gets a certain percentage of improvement, though really
not extraordinary... 30-40% ? maybe it's all the packet-handling going
on around that makes the improvement appear less than it really is?

> > It's probably a good idea to put structures in place, up front, to
> make sure that code compiles across platforms and there are not
> crashes on various processors.  Are #ifdefs enough at this point?  We
> (tigital and myself) are trying to figure out the best way to get this
> altivec code into CVS and have it not impact the x86 side of things.

I'm using function pointer tables. GridFlow contains a table of 888
pointers to functions, and the mmx code replaces 30 of those.

> If it is in some way possible, we should come up with macro's or
> templates for common optimizable functions.

I was using macros for all of that before; now it's more of a mixture of
macros and templates. Some macro definitions contain "template <class
T>" in them and so on.

> If that  is not possible, put the architecture dependend code in its
> own source file, and write a non-altivec version of the same code.

This is exactly what I've done on my side of things. The C code is in
base/number.c; the MMX-dependent source is cpu/mmx.rb, which is a script
that generates cpu/mmx.asm containing the 30 functions, and
cpu/mmx_loader.c that does the function-pointer table surgery.

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju