[GEM-dev] gem cvs question: altivec (SIMD) conventions

[IOhannes m zmoelnig]

cgc at humboldtblvd.com wrote:
> 
> The big problem with run-time checking is that all modern processors have branch
> prediction so that when a conditional is reached it will speculatively execute a
> part of each branch.  If one branch has a SIMD instruction that the machine
> can't handle then the app will segfault with an illegal instruction.  
so we cannot use SIMD-compiled code for non-simd machines (if the 
compiler does not support compilation into SIMD/non-SIMD code: the 
intel-compiler should support this at least)
but of course we can have the generic procedures live next the 
SIMD-procedures without any problem (on SIMD-platforms).
i think it would be easier to code, if you would only have to #ifdef the 
core altivec function and not worry about the generic function.

> The only way that I've seen people do this is runtime module loading like in
> Photoshop.
which would be a lot to administer...


>>that in PixDualObj's the naming is rather arbitrary: 
>>pix_subtract::processYUVAltivec() vs. 
>>pix_chroma_key::processYUV_YUVAltivec()
> 
> 
> pix_chroma_key is a dual pix object and follows the YUV_YUV convention of the
> other dualPix objects.  There could be a RGB_YUV oro YUV_RGB version at some
> point (who knows?).

it was rather the pix_subtract i had in mind with inconsistency.
anyhow, bot are pix dual objects processing two YUV-images and the 
naming scheme is different.
just for not forgetting about it.

> 
> cgc

anyhow, my changes up till now are only
<old>
pix_test::processAltivec(){
#ifdef ALTIVEC
...
#endif
}
</old>
<new>
#ifdef ALTIVEC
pix_test::processAltivec(){
...
}
#endif

so i think i can safely submit these. (but what for ?;-))


mfg.,as.rd
IOhannes