dsound.dll, dlls/dsound/mixer.c -- DSOUND_MixerVol() optimization

baggett.patrick at figglesoftware.com baggett.patrick at figglesoftware.com
Sat Oct 7 12:18:00 CDT 2006


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)?







More information about the wine-devel mailing list