Mupen64Plus

[midna25]

Have you run the code through the Flux Capacitor?

 

[craigix]

FYI: glN64 has no frameskip option currently, which will probably be necessary on the Pandora. I'm seeing the r4300i emulation using 50-75% of the CPU time, audio 10-20%, so that doesn't leave much for graphics. I haven't tried overclocking to see how far I can push it.

Also, the audio output is a bit glitchy, and will block the process from time to time. If you see the CPU usage at less than 100% then this is probably what's happening. So you might want to disable the audio plugin for now.

I'm curious to know how it runs on the beagle with software mode, is it essentially a slide show?

 

[sepp256]

FYI: glN64 has no frameskip option currently, which will probably be necessary on the Pandora. I'm seeing the r4300i emulation using 50-75% of the CPU time, audio 10-20%, so that doesn't leave much for graphics. I haven't tried overclocking to see how far I can push it.

Also, the audio output is a bit glitchy, and will block the process from time to time. If you see the CPU usage at less than 100% then this is probably what's happening. So you might want to disable the audio plugin for now.

I'm curious to know how it runs on the beagle with software mode, is it essentially a slide show?

I wouldn't expect too much speed from Hacktarux's soft graphics plugin as it runs very slowly on the Wii. I think we've observed single digit VI/s using it in Wii64 in conjunction with the dynarec. Also, there are only a couple games that it supports, but you could at least see Mario64 working.

 

[ari64]

FYI: glN64 has no frameskip option currently, which will probably be necessary on the Pandora. I'm seeing the r4300i emulation using 50-75% of the CPU time, audio 10-20%, so that doesn't leave much for graphics. I haven't tried overclocking to see how far I can push it.

Also, the audio output is a bit glitchy, and will block the process from time to time. If you see the CPU usage at less than 100% then this is probably what's happening. So you might want to disable the audio plugin for now.

I'm curious to know how it runs on the beagle with software mode, is it essentially a slide show?

Yes. It's only useful to make sure things are working.

 

[ldesnogu]

I'm seeing the r4300i emulation using 50-75% of the CPU time, audio 10-20%, so that doesn't leave much for graphics.

I wonder how difficult it would be to use the DSP for handling audio. It looks like audio would be a perfect candidate for it.

 

[sold]

I was gonna ask if the DSP would help. I'm no expert like you guys, but that's what I thought the DSP is for

Edit: Out of curiosity, if sound was handled by the DSP and the GPU was taking care of the graphics, the CPU load would be within the Pandoras capabilities, right?

 

[ari64]

Edit: Out of curiosity, if sound was handled by the DSP and the GPU was taking care of the graphics, the CPU load would be within the Pandoras capabilities, right?

Even if you disable audio, it still processes the RSP event list. This is where the CPU time is being used. I don't know how much of this could be offloaded to the DSP, as I haven't looked at it in detail.

Similarly with the video, you can't just send the N64 display lists directly to the GPU, there is going to be some overhead.

 

[craigix]

What speed is your beagle running at?

 

[anexanhume]

What speed is your beagle running at?

18 mph, but we've just put him on a high protein diet.

Edit: Out of curiosity, if sound was handled by the DSP and the GPU was taking care of the graphics, the CPU load would be within the Pandoras capabilities, right?

Even if you disable audio, it still processes the RSP event list. This is where the CPU time is being used. I don't know how much of this could be offloaded to the DSP, as I haven't looked at it in detail.

Similarly with the video, you can't just send the N64 display lists directly to the GPU, there is going to be some overhead.

Well, I think the hope is that audio goes to the DSP, video goes to the GPU, and FP operations take advantage of NEON. If that's the case, the scheduling overheard should be well worth it, no?

 

[ari64]

At the very least, if your registers are going dead after you store them then you can start overwriting the already flushed ones with sign extended words in order to do at least some strds. Of course, right now your registers aren't quite dead, but I talk about that a little more later.

What I was thinking was to store the low words contiguously then the high words, try to allocate the registers in adjacent pairs where possible, even aligned on ARM end (eg, MIPS r1, r2 -> ARM r0, r1). Then strd back the pairs, overwrite them with their sign extensions, and strd those. I don't know how nicely this opportunity presents itself but it's possibly a worthwhile optimization.

This doesn't work very well. You have to allocate not only adjacent pairs, but even/odd pairs (eg r0/r1 is ok, but not r1/r2). Also the strd instruction only allows 8-bit offsets, which isn't large enough to cover the MIPS register set (r1-r31 plus lo/hi takes 264 bytes). I'd have to adjust r11 to point into the middle and then use positive/negative offsets. Doesn't seem worth it considering how little 64-bit code is in most N64 games.

 

[ari64]

What speed is your beagle running at?

500 Mhz. This kernel doesn't have the /sys/devices/system/cpu/cpu0/cpufreq interface so I'd have to do the uboot hack to change it.

Maybe I should find Notaz's patches...

 

[borgqueenx]

What speed is your beagle running at?

500 Mhz. This kernel doesn't have the /sys/devices/system/cpu/cpu0/cpufreq interface so I'd have to do the uboot hack to change it.

Maybe I should find Notaz's patches...

lets hope 720mhz will give it a booster

 

[Pickle]

Seems the mupen dev's have caught on about the work going on: http://www.emutalk.net/showthread.php?p=425729

Well I have some progress, I have run the emulator with the dynarec on and dummyvideo and dumminput (linking issue). And the sound is coming through loud and clear, i ran Super Mario 64. Seems to be running ok, sound is good and fullspeed, although there some slowdown on the mario face section. The in game demo's seem to be less stressful.
at 850 Mhz the in game was between 60%-70% cpu usage, the mario head intro jumps to 90%+

Ive also been looking through the gl plugins and Im thinking more or less there might still be a need for a native ES plugin, be it 1.1 or 2.0. I also have linker issues with what i have so far.

 

[Exophase]

This doesn't work very well. You have to allocate not only adjacent pairs, but even/odd pairs (eg r0/r1 is ok, but not r1/r2). Also the strd instruction only allows 8-bit offsets, which isn't large enough to cover the MIPS register set (r1-r31 plus lo/hi takes 264 bytes). I'd have to adjust r11 to point into the middle and then use positive/negative offsets. Doesn't seem worth it considering how little 64-bit code is in most N64 games.

I did say even aligned. The offsets would be enough for everything but hi/lo which may not even be worth allocating at all. It's just an optimization that provides benefits when it does apply, which even in the example you gave it would. Moreso than the strds upfront would be the benefit from grouping the ldrd since you don't need the high end at all there. I would say it's because of how little 64bit code is used that you should be bothering with things like this.

 

[borgqueenx]

Seems the mupen dev's have caught on about the work going on: http://www.emutalk.net/showthread.php?p=425729

Well I have some progress, I have run the emulator with the dynarec on and dummyvideo and dumminput (linking issue). And the sound is coming through loud and clear, i ran Super Mario 64. Seems to be running ok, sound is good and fullspeed, although there some slowdown on the mario face section. The in game demo's seem to be less stressful.
at 850 Mhz the in game was between 60%-70% cpu usage, the mario head intro jumps to 90%+

Ive also been looking through the gl plugins and Im thinking more or less there might still be a need for a native ES plugin, be it 1.1 or 2.0. I also have linker issues with what i have so far.

Joy! I lm looking forward to the first screenies and videos, and more updates ofcource.

 

[ari64]

Well, I think the hope is that audio goes to the DSP, video goes to the GPU, and FP operations take advantage of NEON. If that's the case, the scheduling overheard should be well worth it, no?

Yes, but the CPU still has to process the RSP lists, upload textures and so on. It's not as if you can offload everything that the RSP does to the GPU.

As for audio on the DSP, there's no existing code that could be used for that.

 

[ari64]

I did say even aligned. The offsets would be enough for everything but hi/lo which may not even be worth allocating at all. It's just an optimization that provides benefits when it does apply, which even in the example you gave it would. Moreso than the strds upfront would be the benefit from grouping the ldrd since you don't need the high end at all there. I would say it's because of how little 64bit code is used that you should be bothering with things like this.

Yeah but then you'd have to keep the odd numbered registers available, which will increase register pressure. So it's not a clear win. I'm working on a few other optimizations right now, maybe I will revisit this later.

 

[calc84maniac]

Seems the mupen dev's have caught on about the work going on: http://www.emutalk.net/showthread.php?p=425729

Well I have some progress, I have run the emulator with the dynarec on and dummyvideo and dumminput (linking issue). And the sound is coming through loud and clear, i ran Super Mario 64. Seems to be running ok, sound is good and fullspeed, although there some slowdown on the mario face section. The in game demo's seem to be less stressful.
at 850 Mhz the in game was between 60%-70% cpu usage, the mario head intro jumps to 90%+

Ive also been looking through the gl plugins and Im thinking more or less there might still be a need for a native ES plugin, be it 1.1 or 2.0. I also have linker issues with what i have so far.

I think this calls for a video...

 

[ari64]

Well I have some progress, I have run the emulator with the dynarec on and dummyvideo and dumminput (linking issue). And the sound is coming through loud and clear, i ran Super Mario 64. Seems to be running ok, sound is good and fullspeed, although there some slowdown on the mario face section. The in game demo's seem to be less stressful.
at 850 Mhz the in game was between 60%-70% cpu usage, the mario head intro jumps to 90%+

The 90%+ bursts are usually just the dynarec compiling a lot of new stuff. This happens when you move into new areas of the code. Hopefully it won't affect gameplay too much. But yes, sometimes you can hear the audio glitch a little bit when it's doing a lot of recompiling.

 

[Pickle]

Well I have some progress, I have run the emulator with the dynarec on and dummyvideo and dumminput (linking issue). And the sound is coming through loud and clear, i ran Super Mario 64. Seems to be running ok, sound is good and fullspeed, although there some slowdown on the mario face section. The in game demo's seem to be less stressful.
at 850 Mhz the in game was between 60%-70% cpu usage, the mario head intro jumps to 90%+

The 90%+ bursts are usually just the dynarec compiling a lot of new stuff. This happens when you move into new areas of the code. Hopefully it won't affect gameplay too much. But yes, sometimes you can hear the audio glitch a little bit when it's doing a lot of recompiling.

You talked about this before, would it be beneficial to keep more recompiled code in memory? I was using top for my measurments and it reported only 30% being used.