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

[Vijay Kiran Kamuju]

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 at figglesoftware.com
<baggett.patrick at 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:
> 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)?
>
>
>
>
>
>
>