Isn't this just a matter of #ifdefs? I don't really think Wine should stick to the lowest common denominator.
I do think that such optimizations should be very well documented and in sync with the original code.
Stephen
On 10/8/06, Roderick Colenbrander thunderbird2k@gmx.net 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.
As mentioned in another part of this thread asm optimizations in Wine aren't preferred.
If you want to optimize Wine's audio performance this isn't really the area where you should look. The main bottlenecks are located in the interaction of dsound with wine's audio layer (oss/alsa) and the native sound drivers (oss/alsa). That is the area which is far from optimal and causes bad sound quality, latencies and other issues.
Roderick
-- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer