Intel Graphics Performance Primitives library

[Hosed]

[drgoldie]

hi,

i use the fixed-point library which is included in the IGPP. i have to say that it is really well done. it works fast and just as specified.

the documentation of the IGPP is just as all the intel performance libs: very sparse and assumes that you're a pro on the subject.

i will soon start using the texturing part too.
if i find out something interesting about it i'll post it here. unfortunatelly the IGPP code does not run on the emulator nor under real windows. so i'll have to write additional texturing code for those platforms too...

does anybody know if the development on the IGPP was really dropped? intel often just doesn't release updates for quite some time...

btw: if you need performance try the intel xscale compiler. i can not tell any details because of NDA but it should soon be released and will change a lot on the performance side of PocketPC devices.

bye,
DANIEL

[Dan East]

[Sergey Chaban]

Straightforward lib is trivial, optimized lib is quite complex (e.g. optimized for XScale like in this case or optimized for general FPU-less RISC machine).
For example, compare their gppDivHP_n_32s routine to naive (32-n).n division implementation [that is (__int32)(((__int64)x << n) / y)].
Intel version is approx. 3 times faster.
However Intel's Inv/Div routines are XScale-only.

SC

[Dan East]

[Sergey Chaban]

[drgoldie]

[pazazzo]

[Dan East]

[drgoldie]

[Hosed]

considering the only accuracy limitations in fixed point math is where you place the point all one would need to do is add an additional parameter to their macros (like Intel did). I'm not seeing how this is a deciding factor for using a library that prevents testing on x86 and is very platform dependent. The latter 2 being far bigger issues for me.

Just an FYI, I developed a full features Fixed-point class in about 3 hours (mostly tracking down bugs). Very easy code to write.

[drgoldie]

it depends on what you want to be able to do.
the simple solution is to use 16-bits only at all, so you can multiply such two values without having an overflow in a 32-bits register.

but 16-bits is just to small.
but if you want to allow all 32-bits being used, you'll have to work with numbers as large as 64-bits. this is where things become more tricky.

if you want to support functions like: sin,cos,sqrt, etc. then things become a lot more difficult.

of course i'd apprechiate to have the source code of the lib. but on the other side, having carefully hand-optimized assembler code from intel is nice too...

DANIEL

[efortier]

[refractor]

[Sergey Chaban]

This ARM docu is very good indeed, but unfortunatelly it doesn't describe some fixed-point techniques that especially useful with ARM CPUs.
Take division for example, they still use integer division, but it's much faster to optimize it with polynomial approximation for 1/x, thus reducing division to a bunch of multiplies and adds.
Same for sqrt.
Sometimes quality also depends on the compiler, for example check out assembly generated by EVC for the code like this:
fixed z = (fixed)(((__int64)x * y) >> 16);
i.e. 16.16 multiply (GCC generates better code in this case BTW);
In fact for multiplication it's even faster to use ARM assembly routine despite the call overhead.
Another example is CPU-specific optimizations - e.g. for stuff like vector dot product it's faster to use certain ARM specific instructions. Or CLZ on XScale to speedup operand normalization for the div approximation above.
If there is no 64-bit mul instruction in the target CPU, that's another set of optimized routines.
Also float<->fixed conversion for FPU-less processors.
That's why really fast fixed-point math library is not exactly trivial
That said I guess that even really simple implementation is still good enough in most cases, even for games.

SC