|
»
« Return to Thread: OpenALsoft CPU usage?
Re: OpenALsoft CPU usage?
by Christian Ohm
::
Rate this Message:
On Tuesday, 26 May 2009 at 9:06, Chris Robinson wrote:
> Those results are pretty odd. All that patch does is add 8 floating-point
> additions per sample, which is comparatively minor compared to what it already
> did.
>
> Maybe because the sends are being updated through a pointer to an array in the
> source struct, it's not optimizing it as well as when it was on the stack..
> I'll have to see if putting them back on the stack helps at all.
>
> Also FYI, I made a bit of a change in the GIT version to the ALSA backend
> which may help the mixer's efficiency a bit. Not sure how much of an effect
> it'll have if the sample mixing loop is being a killer, though.
Hello,
I finally got around to doing some more testing. I used altest from
svn://connect.creativelabs.com/OpenAL/trunk/contrib/tests/altest (a bit
modified to remove useless output, use the default device, start the multiple
sources test automatically, and change the number of sources it uses, see
http://pastebin.com/f24b34374). System is the same as last time, 64 bit Debian
unstable, 2 x 2.6 GHz X2, fixed to 2,6 GHz (forgot that last time, though with
oprofile's relative percentages it didn't matter that much), CPU usage as shown
by htop.
1.7 (the version from Debian) uses up to 20% CPU at up to 36 sources, then each
additional source adds a significant amount, at 41 sources it's at 80%, above
that at 95% (but I think just because Linux doesn't give it the full 100%).
Current git does 36 sources at 10%, and scales linearly with 128 sources at 30%
and the maximum of 256 sources at 60%.
Nice work so far. I hope you can release this soon, since we currently get
quite a few complaints about Warzone's CPU usage due to people using OpenAL
Soft 1.7, and we have to tell them to downgrade to fix this. More performance
optimizations would of course be welcome (I think Warzone uses one source per
unit, with 8 x 300 units maximum - we should probably fix this), but the
current git will at least not overload (fast) CPUs anymore.
Best regards,
Christian Ohm
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel
> Those results are pretty odd. All that patch does is add 8 floating-point
> additions per sample, which is comparatively minor compared to what it already
> did.
>
> Maybe because the sends are being updated through a pointer to an array in the
> source struct, it's not optimizing it as well as when it was on the stack..
> I'll have to see if putting them back on the stack helps at all.
>
> Also FYI, I made a bit of a change in the GIT version to the ALSA backend
> which may help the mixer's efficiency a bit. Not sure how much of an effect
> it'll have if the sample mixing loop is being a killer, though.
Hello,
I finally got around to doing some more testing. I used altest from
svn://connect.creativelabs.com/OpenAL/trunk/contrib/tests/altest (a bit
modified to remove useless output, use the default device, start the multiple
sources test automatically, and change the number of sources it uses, see
http://pastebin.com/f24b34374). System is the same as last time, 64 bit Debian
unstable, 2 x 2.6 GHz X2, fixed to 2,6 GHz (forgot that last time, though with
oprofile's relative percentages it didn't matter that much), CPU usage as shown
by htop.
1.7 (the version from Debian) uses up to 20% CPU at up to 36 sources, then each
additional source adds a significant amount, at 41 sources it's at 80%, above
that at 95% (but I think just because Linux doesn't give it the full 100%).
Current git does 36 sources at 10%, and scales linearly with 128 sources at 30%
and the maximum of 256 sources at 60%.
Nice work so far. I hope you can release this soon, since we currently get
quite a few complaints about Warzone's CPU usage due to people using OpenAL
Soft 1.7, and we have to tell them to downgrade to fix this. More performance
optimizations would of course be welcome (I think Warzone uses one source per
unit, with 8 x 300 units maximum - we should probably fix this), but the
current git will at least not overload (fast) CPUs anymore.
Best regards,
Christian Ohm
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel
« Return to Thread: OpenALsoft CPU usage?
| Free embeddable forum powered by Nabble | Forum Help |
