Page 3 of 3

Re: N64 benchmarks

Posted: Sat Dec 15, 2018 12:45 pm
by calima
I actually want to target 64 kbps or lower, 96 was just the lowest listening test that included musepack.

F-Zero X seems to be a form of 16-bit ADPCM:
https://fzerocentral.org/viewtopic.php?t=14170
https://github.com/jombo23/N64-Tools/tr ... oolUpdated

edit: and apparently it spent 35mb on music alone.

Re: N64 benchmarks

Posted: Sat Dec 15, 2018 1:06 pm
by lidnariq
What's the computational load for a softsynth vs a decoder?

Re: N64 benchmarks

Posted: Sun Dec 16, 2018 3:18 am
by calima
MIDI playback can be fast, but at least timidity is about 10x slower vs vorbis decoding on x86_64. Lots of official N64 games used MIDI, but it's quite a lot easier to find musicians for normal formats vs MIDI. I'm not otherwise opposed to MIDI or tracker approaches, though finding optimized, liberally licensed decoders and sample banks might also be an issue.

Re: N64 benchmarks

Posted: Sun Dec 16, 2018 12:18 pm
by calima
cen64 is now able to profile.

Re: N64 benchmarks

Posted: Mon Dec 17, 2018 4:10 am
by calima
ERP, a commercial N64 dev, mentions on beyond3d that the RDRAM random latency is 64 cpu cycles. Putting it here too to spread the info. That's almost modern-cpu level cost for a cache miss, damn.

Re: N64 benchmarks

Posted: Mon Dec 17, 2018 10:18 am
by 93143
My understanding is that this wasn't just the inherent RDRAM latency, but the total cost of the CPU having to interface with the RAM via the memory controller on the RCP. I also didn't get the impression that it was always exactly 64 cycles; that number might be an average or a worst-case scenario.

But yes, it's been noted that optimizing for size often gives the best speedup with N64 code...

Re: N64 benchmarks

Posted: Mon Dec 17, 2018 11:18 am
by calima
I had tried that with some of the audio codecs, and -Os was something like 20% slower than -O3.

Re: N64 benchmarks

Posted: Mon Dec 17, 2018 11:41 am
by 93143
Obviously it depends on the code, and presumably the compiler too. I just meant that cache misses are known to be a fairly big deal on N64, and since the cache is not huge, it's something to watch out for.

Re: N64 benchmarks

Posted: Tue Dec 18, 2018 7:15 pm
by Jarhmander
calima wrote:I had tried that with some of the audio codecs, and -Os was something like 20% slower than -O3.
I didn't try with MIPS, however something that I observed is that gcc often generates smaller code with -O3 than with -Os, at least when compiling for ARM Cortex-M3 devices. That alone may explain the difference.

Re: N64 benchmarks

Posted: Sat Jan 05, 2019 12:23 pm
by calima
Did a video test, just for fun and to see what the scale would be. I couldn't find any liberally licensed mpeg1, mpeg2, or mpeg4 decoders, so I just did one test with Xvid (which is GPL).

The results are rather astounding. Even though it's the Simple profile, lacking in quality compared to xvid with its full features, it should still look better than mpeg1 and many mpeg2 streams. 98% realtime and quite watchable quality. The color conversion can provably be done by the RSP, and the texture filter supports YUV natively too. All just with C, xvid has no mips optimizations.

At the bitrate used, 247 kbps, add 64 kbps for audio, and that makes 40 kb/s, 2.4 mb/min of video. That's plenty of FMVs.

Re: N64 benchmarks

Posted: Sat Jan 05, 2019 1:25 pm
by tepples
Sorenson Spark and Xvid are codecs in the H.263 family. Their R/D is a step above MPEG-2 but just below H.264. How well does Theora run? It's BSD licensed, and its R/D should be comparable to Xvid.

Re: N64 benchmarks

Posted: Sun Jan 06, 2019 2:48 am
by calima
Theora is several times slower on x86, so not even worth trying. Its quality is also lower.