[Openal-devel] [Fwd: [PATCH] MMX routines for mixing audio (linux) (v2)]

[Prakash Punnoor]

Stephen J Baker schrieb:
> Prakash Punnoor wrote:
> 
>> I mean, I can do better things with my spare time, if there is no
>> interest from OpenAL side...(If I just wanted it for my private use, I'd
>> probably hadn't spent the time for the second version.) I heard
>> someone asking
>> for more Linux devs, but currently motivation from OpenAL dev side is
>> not high
>> to contribute...
> 
> 
> I am very interested in this patch.  I don't know enough about SSE to
> contribute to it - but I'll be first in line to actually use it!
> 
> The Linux version of OpenAL is certainly in need of enthusiastic
> developers.

Well, I am not sure whether SSE can be used in large parts of OpenAL (except
memcpy replacemnts, of course), as I understood it, OpenAL rather uses integer
than floating point maths - so here MMX is preferred. One place where SSE
might make sense is the float_mul function. Some months ago when I profiled
OpenAL this function was on top of the list (currently I have troubles using
oprofile with openal; I just don't see what is causing the trouble...). But In
fact I am also thinking of trying to completely elimiante the rare floating
point usage in OpenAL, as converting floats to integers is rather costly...and
 then MMX could be used to speed up things and MMX is avaiable on much more
x86 CPUs than SSE(2).

> 
>> which CPU instructions are available. But this is something you or
>> some other
>> OpenAL maintainer should design, as I am not keen on writing some code
>> which
>> won't get accepted anyway.
> 
> 
> It's hard to imagine why it wouldn't be accepted if:
> 
> a) It works.
> b) It builds and runs cleanly on a wide variety of CPU's without causing
>    extra installation hassles.
> 
> From what I understood, those two criteria have been met - right?


Well, from my tests, yes, but it needs more testing. I'd be happy if you try
out the patch and report success/failure. I wrote about the limitations/room
for improvements (which it certainly has) in my submitting email. Furthermore,
if you follow lkml and the current reiser4 debate, you'll then see another
strong point missing in your list: coding style/maintainability. So even if a)
and b) holds, the OpenAL devs will probably have some suggestions about this
mentioned point.

Cheers,

-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V