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