portlibs - Tremor

Anyone know of an optimised Ogg decoder somewhere that uses floating point? Tremor seems very CPU heavy as its integer based.
But at a pinch I'm happy to use tremor as it does what I need.

This bit may help others....
It took me a while to find the ogg decoder 'tremor-lowmem-ppc.tar' found at [sourceforge.net]
(Didn’t look in portlibs at first coz I thought it was about ports - guess it stands for "portable libraries")


Also I don't think any wii brew pages have a link for Tremor - I only found out it existed as one of the sound libs talked about it.
Anyone mind it I add a few links to any missing libs to the Wii Brew 'List of development tools?

What makes you think Tremor uses more CPU because it's integer based?

Here's a quick test using MPlayer.

Tremor:
BENCHMARKs: VC: 0.000s VO: 0.000s A: 13.958s Sys: 0.021s = 13.980s
BENCHMARK%: VC: 0.0000% VO: 0.0000% A: 99.8479% Sys: 0.1521% = 100.0000%

ffvorbis:
BENCHMARKs: VC: 0.000s VO: 0.000s A: 7.413s Sys: 0.022s = 7.435s
BENCHMARK%: VC: 0.0000% VO: 0.0000% A: 99.6976% Sys: 0.3024% = 100.0000%

ffvorbis might be 50% faster, but decoding OGG isn't a really expensive operation. GuitarsOnFire decodes up 3 ogg streams at the same time in realtime without any problems, while doing all the other game logic.
Also, I think ffvorbis makes heavy use of SIMD instructions, so comparing them on x86 is not a fair game.

If you see 'performance' problems due to OGG playback then it's IO related. When I tried to stream OGG files from SD cards with GuitarsOnFire I ran into all kinds of performance problems. I don't know if it's libogc/libfat or hardware related, but streaming more then 1 ogg file from SD card at a time caused problems for me. So I just load the whole files in memory and then stream the file from memory.

Thanks everyone,
Yes looks like one of my bottle necks was mainly I/O
I’m now decoding the stream(s) to memory first at game start-up, my plan was to generate wav’s and store them to SD on the very first run, but it looks like it’s going very quick using just memory and decoding each time at start-up.

As for Tremor using more CPU time – Floating point emulation just does!
I’m not having a go at tremor; its whole design is to avoid floating point, which is a fantastic feat.
Tremor (Wii lib is the low mem version) is quick but it’s never going to be as accurate or as optimised as something decoding ogg’s using a FPU.

Hum, fixed-point was generally used because it is more optimized than floating-point, not the contrary, because calculations using FPU were slower than calculations using Integer Unit. That's might not be the case anymore on modern DSPs or some CPU but I doubt the Wii PowerPC is more efficient with floating point instructions (see this article: [www.mactech.com] )

Sure fixed-point is less accurate because of the limited bits resolution but I doubt you are going to notice any differences in case of OGG decoding.

If you want fast I/O you can use the /tmp directory on the wii's NAND. There's nothing important in there and it gets wiped every time a new IOS is loaded. Perfect for buffering large game files (or virtual memory, if you're hardcore).

I would say benchmark the floating point decoder again (on the wii) with a concurrent thread running that is also using the floating point registers. Normally libogc cheats when doing thread context switches by not saving/restoring the FPRs, but it can't do that if more than one thread is using floating point (such as a graphical game with music decoding happening in a separate task). This would knock down the performance gain a bit, considering it has to go through an exception handler to do it.



Edited 1 time(s). Last edit at 04/29/2011 11:30AM by tueidj.

Quote
ekeeke
Hum, fixed-point was generally used because it is more optimized than floating-point, not the contrary, because calculations using FPU were slower than calculations using Integer Unit. That's might not be the case anymore on modern DSPs or some CPU but I doubt the Wii PowerPC is more efficient with floating point instructions (see this article: [www.mactech.com] )

Tremor was designed for embedded applications where a FPU wasn't available, or implemented via software emulation. Think early ARM CPUs, like all those old nokia and winCE devices. The PowerPC is (comparatively) a beast when it comes to FPU, plus it lightens register pressure (freeing up GPRs by using FPRs instead).
(Rolling your own fixed-point assembly routines is never a bad thing though.)

All this has given me another thought!

If something is doing tones of maths and not using the FPU, maybe share some of the workload with the FPU so it can do it in parallel. I’m guessing it would work.
Now this is a wild guess, but hell you might even find that doing everything in floats is more efficient due to the wii’s architecture, after all the FPU is build to crunch numbers.

Quote
Daid
Also, I think ffvorbis makes heavy use of SIMD instructions, so comparing them on x86 is not a fair game.

Actually, this was a Wii benchmark.

Quote
Titmouse
All this has given me another thought!

If something is doing tones of maths and not using the FPU, maybe share some of the workload with the FPU so it can do it in parallel. I’m guessing it would work.
Now this is a wild guess, but hell you might even find that doing everything in floats is more efficient due to the wii’s architecture, after all the FPU is build to crunch numbers.

That's pretty much what my previous comment was about, re: PowerPCs being awesome at floating point (which is part of the reason they're used for all the big name consoles) and FPRs vs. GPRs. We already know it's not a wild guess due to Extrems' benchmark... my remaining question is how well does it stand up when the extra step of switching the FPU state is needed after switching threads. There's more info about what I'm talking about in this thread (did you ever track down that bug Eke?).

Quote
tueidj
There's more info about what I'm talking about in this thread (did you ever track down that bug Eke?).

Nope, i gave up investigating that one since the workaround (disabling interrupts during FPU calculations) did the trick

Definitely sounds like a callback or timer-triggered function (using SYS_SetAlarm/SYS_SetPeriodicAlarm) was using floating point. I've seen it happen when a timed callback is used to poll the wiimote.

I think you are right, I totally forgot that IRQ_Disable() function would not only disable IRQ Exception but also Decrementer Exception, which is responsible of alarm callbacks. I was looking into the various IRQ handlers with no luck but periodic alarm callbacks set by the system could indeed explain the whole issue.

EDIT: Ok now I feel stupid, it was even more simple than that but it's what you said about polling the wiimote that lead me to the solution. My VSYNC handler is indeed programmed to call WPAD_ScanPad, which off course make use of floating point calculations. So the mistake is entirely on my side, not in libogc code (I didn't found any periodic alarm callback that use floating point by the way).



Edited 1 time(s). Last edit at 04/30/2011 10:09PM by ekeeke.

Actually I took a quick look at the GenPlusGX source, it looks like you're doing WPAD reading in the VI retrace callback - that would cause the same problem.

Edit: Ah you found it too ;)



Edited 1 time(s). Last edit at 04/30/2011 10:12PM by tueidj.