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

[Mirek]

What platform does not have MMX instructions and is now supported, is it 
problem to detect if CPU have MMX and use it if is it possible? Because 
speed improvment is always wantable.

Mirek

Vijay Kiran Kamuju napsal(a):
> 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)?
>>
>>
>>
>>
>>
>>
>>
> 
> 
>