Hi,
using MMX/SSE2 means it would be platform/architecture specific code. we should be platform independent as possible.
Thank, VJ
On 10/7/06, baggett.patrick@figglesoftware.com baggett.patrick@figglesoftware.com wrote:
I was reading through dlls/dsound/mixer.c and I came across the function DSOUND_MixerVol() that really stood out. The purpose of the code it to apply a volume amplification by multiplying the channel data by the amplification factor. What *really* struck me was the parallelism that could be achieved using SIMD instructions (I am the author of the project SIMDx86 on Sourceforge):
for (i = 0; i < len; i += 2) { *bps = (*bps * dsb->cvolpan.dwTotalLeftAmpFactor) >> 16; bps++; } The segment below it for stereo sound not shown but is basically the same thing.
This could be done extremely easily using MMX, which could process 32 samples/loop interation, or SSE2 which could process 64 samples/loop (actually, more, but cache lines aren't that big yet). With the addition of some aggressive prefetching, there could be a signifigant speed up. Now, here is the question:
What is WINE's policy toward:
- Optimizations, rather than bugfix patches.
- Inline assembly language (allowed, disallowed)? Inline assembly
language for the purpose of optimization (instead of, say, fixing up stack)? 3) Function pointers to select optimal code paths? 4) Detecting/using enhanced x86 instruction sets (e.g. MMX/SSE2)? Is there still an effort to make WINE work with non-x86? (DarWINE or something)?