I added some more yuv processing to pix_add, diff, multiply, and subtract. I'm not sure if it's possible for someone to check for functionality on Windows or Linux, but the compile needs to be checked at the very least. I don't think anything will go wrong, but you never know.

Also, what are people's thoughts on optimizing the code? For example, I rewrote, but haven't committed, the RGBA part of pix_gain to use ints rather than floats in the loop and it's twice as fast now on PPC. A lot can be done with the pix_ code in terms of optimization. Here's a breakdown of CPU use for various pix_gain functions on a 1ghz g4 processing DV_NTSC at 30fps:

pix_gain - original RGBA- 49% cpu use pix_gain - int rewrite RGBA - 24% pix_gain - yuv scalar - 14% cpu pix_gain - yuv altivec - 2% cpu

Obviously these results show that performance gains can be huge if certain optimizations are done. Is any one doing this for x86? I see that there are two MMX functions that someone added, are there plans for more? 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.

best cgc

On Wed, 29 Jan 2003, chris clepper wrote:

Left out a paragraph that's now gone to the cut and paste gremlin, so i'll paraphrase:

Part of the point about the pix_gain illustration is not that altivec or my scalar code kick ass, but that the original pix_gain code could actually run faster than my changes on a different platform. There should be a fair amount of testing when these things are changed, for compatibility, stability, and performance. It's not possible for each developer to know the ins and outs of tweaking each and every platform and compiler, so some collaboration is necessary on the shape of the code.

Right. Generally I can say that moving to integer calculation will not do harm in any case (well at least not in terms of speed).

Write down you investivations about speed in some file on CVS, with instructions how you tested it. This way others can contribute and we get a picture of what runs where and how.

Anyway I really just wanted to open up a discussion about making GEM really fly on all platforms. ;)

On a somewhat related note: Is there someone building a Windows version of the CVS? I have a win2k box with pre-CVS GEM and no compiler, and would like to check out how the CVS version runs on it.

What about moving the build system to gcc on windows too. Should be possible, no ? I am probably going to try this out with pd in the next days.

Guenter

Hallo,

chris clepper hat gesagt: // chris clepper wrote:

It seems like it would indeed be possible. Does gcc require Cygwin or some type of Unix environment to be installed?

gcc is a part of the Cygwin distribution, but there also is MinGW (Minimalist Gnu for W32, http://www.mingw.org/) that IIR doesn't require a full Unix-like environment. But I never used those, gcc comes built into my Linux system ;)

ciao

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

...

...

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?

i got some (at first glance) counterintuitive results using mmx in pdp too. i guess a lot of this strangeness has to do with memory bandwidth. simple operations like add or scale are not much faster than their scalar integer c counterparts. i did get a lot of speedup for the more compute intensive stuff like the biquad filters, iterated convolution and basicly anything that needs to do a lot of clipping. also i try to limit the data copying to a minimum in pdp, this seems to help too..

the general rule seems to be: keep your memory accesses local and your data size small: do as much as possible inside the pixel loop, or iterate several times over 1 scanline instead of the whole image.

These points seems to hold true for all SIMD types. Altivec is pretty much limited by memory bandwidth so it pays to do as much calculation on the data between memory accesses. In Altivec, there are also cache control functions to open up dedicated cache-lines to the vector unit, which help decrease memory load latencies. Maybe there exists something similar to this for MMX?

The structure of the processing chain is also a big factor. GEM is basically a chain of for loops, which probably isn't ideal, but it is quite flexible.

Matju, is GridFlow building a single loop and filling it with functions from a table? That seems like it could be really efficient, especially with the decrease in memory accesses between objects.

It's great that we are sharing all of these tips, findings and ideas, among developers working on various projects.

cgc

tom

On Thu, 30 Jan 2003, chris clepper wrote:

On Thu, 30 Jan 2003, Tom Schouten wrote:

...

i got some (at first glance) counterintuitive results using mmx in pdp too. i guess a lot of this strangeness has to do with memory bandwidth. simple operations like add or scale are not much faster than their scalar integer c counterparts.

You have to be careful to do the same optimisations in asm as in C code... I have done that mistake...

...

also i try to limit the data copying to a minimum in pdp, this seems to help too..

I haven't got to the point where data copying is really minimized in my software, but this task is much more of a challenge for me, as the data my objects accept are of wildly differing dimensions, so there's a clash between the strategies for handling small chunks and big chunks of data.

The structure of the processing chain is also a big factor. GEM is basically a chain of for loops, which probably isn't ideal, but it is quite flexible. Matju, is GridFlow building a single loop and filling it with functions from a table?

No, it is a packet-based system. A grid message contains the GridOutlet pointer of the sender; the receivers return their GridInlet pointers. Then the sender tells GridOutlet to send() or give(), which may buffer and/or send packets to the GridInlets. Then the GridInlets may slightly repacketize the data so that it comes in nice multiples of N (as specified by receivers for their own convenience...). And then object-specific code is called with a packet as a parameter... and so on...

In GridFlow there is a distinction between a "numeric operator" and a "grid operator". The former is really simple, it is a function that takes one or two arguments of a given number type (but actually every such operator comes with six differently vectorized versions of itself). The latter is quite complex code that may involve any number of nested for-loops in non-obviously-optimisable ways.

So what happens typically is that on a given chunk of data, a vectorized numeric operator is called, and then another is called, etc., in the midst of higher-level loops and memcpy()'s and so on. The result is that there is a lot of RAM access, *BUT* it is mostly at the cache level because of the packetizing.

That seems like it could be really efficient, especially with the decrease in memory accesses between objects.

I very well see myself adding a runtime machine code generator to GridFlow, which would take a few loop forms and fill-in the blanks. Right now, however, the strangest I've done is writing a script that generates GridFlow's _asm_ code. I still have to use the "nasm" program to convert to *.o and link it into gridflow.so ... And then I still have to figure out how that generator would fit with my processing model (I already have a few ideas)

This would be, of course, pentium-only (... for as long as I'm the only person working on GridFlow; i only have PC's)

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

MMX is only coded in asm right?

gcc has c extensions for mmx, but compared to the apple altivec ones, these look much worse than the plain assembly imho..

That makes it that much harder for anyone who's not already an assembly expert. Altivec is at least C based functions and data types, but still tricky to learn. PDP is using some MMX on yuv pixels from the looks of it, maybe the results are better processing 16 bit pixels vs 32bit ones?

to clear things up, pdp uses 24bit/pixel (96bit per 2x2 macropixel). 16 bit for the luma plane and 16 bit for 2x2 subsampled chroma planes. before release i did an 8 bit / component version (12bit/pixel) but it is too small if you want to do feedback stuff and want some headroom to play with. also since all mmx integer multiplications are 16bit, this cuts down on conversions..