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, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> 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:
1) Optimizations, rather than bugfix patches.
2) 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)?
