Why EXACTLY is GameCube emulation so "unachievable"?


EssoAir

Well-Known Member
Joined
Dec 13, 2012
Messages
1,822
Location
Knoxville/Seattle
I understand many topics have been made about this before. However, none of them go into the specifics. I am curious why Dolphin Emulator will not run on a Pandora. I know that even on the 1ghz unit it would likely be about 1.5 FPS, but that's a good start in my opinion. So why is everyone so afraid to try?
 
Id imagine the gamecube is simply too powerful by far, to emulate on a 1ghz or even a 1ghz 1.5. I mean it was on par with the xbox i believe except it didnt have as much capability for textures and such. If dreamcast wont run i cant see gamecube running.
 
Dreamcast does NOT run just fine on Pandora, it's slow as hell, and Gamecube is a lot more powerful than Dreamcast. Frankly, this question is like asking an astrophysicist why going to Alpha Centauri in a year is so unachievable. You should try doing a little more research on your own, at least before casting doubt on this.


Look at how Dolphin performs on computers that are much more powerful than Pandora. It's pretty decently optimized there, so I can tell you right off the bat that you'll have a hard time getting much better performance, if you can at all.


You can divide Dolphin's emulation into three big performance critical sections: CPU, GPU, and DSP (audio). Any decently written Gamecube emulator will probably follow the same pattern. All three of them need some level of CPU resources on the host machine.


To emulate Gecko (Gamecube's CPU) you need a CPU which is much more powerful, because of the overhead involved. In the case of emulating it on ARM that means you have to spill registers because there are fewer on ARM, you have to do something to map the different sort of flags and handle competition between the emulated flags, registers, etc and those needed additionally by the emulator. You have to perform extra work for translating indirect branches, counting cycles, and so on. But maybe the biggest cost is that you have to check all memory accesses to map them to emulated memory, which typically includes the game's attempts to directly access hardware peripherals. You can use the OS/MMU to help you to some extent but usually not 100%, because then you end up with too many expensive traps (which cost hundreds of times more than direct emulation). And somewhere in there you have to check for code modification.


Clock for clock Pandora's CPU is probably not as fast as Gecko, at least not when running the same kind of code. Gecko is mildly out of order with register renaming, has a much smaller pipeline and therefore much smaller branch misprediction penalty, has faster branches in general (because of a BTIC that can hide branch fetch bubbles), has lower latency caches and fewer interlock conditions. And Gecko has full speed double precision floating point while on Pandora it's super slow. Pandora has a little more clock speed to compensate, or a lot more (twice as much) on the 1GHz models. But the real killer is the memory latency. Gamecube is optimized to use a fast pool of 1T SRAM that's really low latency. Pandora's main RAM, on the other hand, is really high latency. There's no way you can make up that difference.


The GPU is a massive hurdle too. Gamecube's GPU Flipper is probably already more powerful than Pandora's SGX530. Add to that both CPU and GPU overhead for texture caching and mapping primitives that aren't directly supported. Even worse, on Pandora the GPU drivers need a ton of CPU time handling scenarios that are very inexpensive on consoles (lots of state changes). They tend too much CPU time regardless. This takes a big hit on N64 emulation and it'll probably take a bigger hit here. Worse than on Dreamcast emulation, because Dreamcast games have to prepare an entire scene in advance and are a closer fit to Pandora's GPU since they have the same lineage.


DSP needs more CPU time yet, especially if using the LLE emulation which is necessary to get a lot of games sounding right.


You might ask why someone doesn't port Dolphin anyway. The reason is because there's a ton of platform specific work that hasn't been done, in order to get the best performance - and the difference between a direct port (assuming it even has an interpreter and soft renderer) and an optimized one would probably be at least an order of magnitude, so you'd most likely be looking at below 1FPS. That's not worth anyone's time even if that port just takes a few days. But the work needed to bring it to optimization parity with the PC versions would at least require an ARM recompiler (probably targeting NEON for paired singles) and GPU emulation targeting OpenGL ES 2 and all its limitations vs whatever the current plugins can use. This is a huge amount of work. It could require hundreds or even thousands of man hours to develop and test.
 
Last edited by a moderator:
I can count the cycles, if it can help...

Frankly, this question is like asking an astrophysicist why going to Alpha Centauri in a year is so unachievable.
Can't stop laughing on this :D .
 
Last edited by a moderator:
Dreamcast does NOT run just fine on Pandora, it's slow as hell, and Gamecube is a lot more powerful than Dreamcast. Frankly, this question is like asking an astrophysicist why going to Alpha Centauri in a year is so unachievable. You should try doing a little more research on your own, at least before casting doubt on this.


Look at how Dolphin performs on computers that are much more powerful than Pandora. It's pretty decently optimized there, so I can tell you right off the bat that you'll have a hard time getting much better performance, if you can at all.


You can divide Dolphin's emulation into three big performance critical sections: CPU, GPU, and DSP (audio). Any decently written Gamecube emulator will probably follow the same pattern. All three of them need some level of CPU resources on the host machine.


To emulate Gecko (Gamecube's CPU) you need a CPU which is much more powerful, because of the overhead involved. In the case of emulating it on ARM that means you have to spill registers because there are fewer on ARM, you have to do something to map the different sort of flags and handle competition between the emulated flags, registers, etc and those needed additionally by the emulator. You have to perform extra work for translating indirect branches, counting cycles, and so on. But maybe the biggest cost is that you have to check all memory accesses to map them to emulated memory, which typically includes the game's attempts to directly access hardware peripherals. You can use the OS/MMU to help you to some extent but usually not 100%, because then you end up with too many expensive traps (which cost hundreds of times more than direct emulation). And somewhere in there you have to check for code modification.


Clock for clock Pandora's CPU is probably not as fast as Gecko, at least not when running the same kind of code. Gecko is mildly out of order with register renaming, has a much smaller pipeline and therefore much smaller branch misprediction penalty, has faster branches in general (because of a BTIC that can hide branch fetch bubbles), has lower latency caches and fewer interlock conditions. And Gecko has full speed double precision floating point while on Pandora it's super slow. Pandora has a little more clock speed to compensate, or a lot more (twice as much) on the 1GHz models. But the real killer is the memory latency. Gamecube is optimized to use a fast pool of 1T SRAM that's really low latency. Pandora's main RAM, on the other hand, is really high latency. There's no way you can make up that difference.


The GPU is a massive hurdle too. Gamecube's GPU Flipper is probably already more powerful than Pandora's SGX530. Add to that both CPU and GPU overhead for texture caching and mapping primitives that aren't directly supported. Even worse, on Pandora the GPU drivers need a ton of CPU time handling scenarios that are very inexpensive on consoles (lots of state changes). They tend too much CPU time regardless. This takes a big hit on N64 emulation and it'll probably take a bigger hit here. Worse than on Dreamcast emulation, because Dreamcast games have to prepare an entire scene in advance and are a closer fit to Pandora's GPU since they have the same lineage.


DSP needs more CPU time yet, especially if using the LLE emulation which is necessary to get a lot of games sounding right.


You might ask why someone doesn't port Dolphin anyway. The reason is because there's a ton of platform specific work that hasn't been done, in order to get the best performance - and the difference between a direct port (assuming it even has an interpreter and soft renderer) and an optimized one would probably be at least an order of magnitude, so you'd most likely be looking at below 1FPS. That's not worth anyone's time even if that port just takes a few days. But the work needed to bring it to optimization parity with the PC versions would at least require an ARM recompiler (probably targeting NEON for paired singles) and GPU emulation targeting OpenGL ES 2 and all its limitations vs whatever the current plugins can use. This is a huge amount of work. It could require hundreds or even thousands of man hours to develop and test.

Sorry to get you heated, but this is precisely what I was hoping for. Thank you for actually explaining and not just saying "no, too hard"
 
Last edited by a moderator:
I don't remember the ~basic rule, if 2x or 10x the horsepower is needed to run a good emulation.
 
Dreamcast does NOT run just fine on Pandora, it's slow as hell, and Gamecube is a lot more powerful than Dreamcast. Frankly, this question is like asking an astrophysicist why going to Alpha Centauri in a year is so unachievable. You should try doing a little more research on your own, at least before casting doubt on this.


Look at how Dolphin performs on computers that are much more powerful than Pandora. It's pretty decently optimized there, so I can tell you right off the bat that you'll have a hard time getting much better performance, if you can at all.


You can divide Dolphin's emulation into three big performance critical sections: CPU, GPU, and DSP (audio). Any decently written Gamecube emulator will probably follow the same pattern. All three of them need some level of CPU resources on the host machine.


To emulate Gecko (Gamecube's CPU) you need a CPU which is much more powerful, because of the overhead involved. In the case of emulating it on ARM that means you have to spill registers because there are fewer on ARM, you have to do something to map the different sort of flags and handle competition between the emulated flags, registers, etc and those needed additionally by the emulator. You have to perform extra work for translating indirect branches, counting cycles, and so on. But maybe the biggest cost is that you have to check all memory accesses to map them to emulated memory, which typically includes the game's attempts to directly access hardware peripherals. You can use the OS/MMU to help you to some extent but usually not 100%, because then you end up with too many expensive traps (which cost hundreds of times more than direct emulation). And somewhere in there you have to check for code modification.


Clock for clock Pandora's CPU is probably not as fast as Gecko, at least not when running the same kind of code. Gecko is mildly out of order with register renaming, has a much smaller pipeline and therefore much smaller branch misprediction penalty, has faster branches in general (because of a BTIC that can hide branch fetch bubbles), has lower latency caches and fewer interlock conditions. And Gecko has full speed double precision floating point while on Pandora it's super slow. Pandora has a little more clock speed to compensate, or a lot more (twice as much) on the 1GHz models. But the real killer is the memory latency. Gamecube is optimized to use a fast pool of 1T SRAM that's really low latency. Pandora's main RAM, on the other hand, is really high latency. There's no way you can make up that difference.


The GPU is a massive hurdle too. Gamecube's GPU Flipper is probably already more powerful than Pandora's SGX530. Add to that both CPU and GPU overhead for texture caching and mapping primitives that aren't directly supported. Even worse, on Pandora the GPU drivers need a ton of CPU time handling scenarios that are very inexpensive on consoles (lots of state changes). They tend too much CPU time regardless. This takes a big hit on N64 emulation and it'll probably take a bigger hit here. Worse than on Dreamcast emulation, because Dreamcast games have to prepare an entire scene in advance and are a closer fit to Pandora's GPU since they have the same lineage.


DSP needs more CPU time yet, especially if using the LLE emulation which is necessary to get a lot of games sounding right.


You might ask why someone doesn't port Dolphin anyway. The reason is because there's a ton of platform specific work that hasn't been done, in order to get the best performance - and the difference between a direct port (assuming it even has an interpreter and soft renderer) and an optimized one would probably be at least an order of magnitude, so you'd most likely be looking at below 1FPS. That's not worth anyone's time even if that port just takes a few days. But the work needed to bring it to optimization parity with the PC versions would at least require an ARM recompiler (probably targeting NEON for paired singles) and GPU emulation targeting OpenGL ES 2 and all its limitations vs whatever the current plugins can use. This is a huge amount of work. It could require hundreds or even thousands of man hours to develop and test.

So you're saying decent Dreamcast is possible ? :p which is what everybody wants
 
So ARM is not supported?

Well if the source code is available and ARM based processors make a huge improvement we may have dolphin running 2 or 3 frames a second within the next 5 years or so if we're lucky.
 
Last edited by a moderator:
What about a 2ghz ARM device?

Clock speed isn't everything, you can't compare GHZ.. Hell There were Pentium 4's that ran over 3Ghz that can't match the performance of a 1.2Ghz Core processor.. Also the GPU is a big obstacle, regular PCs use huge video cards drawing hundreds of watts of power to accomplish heavy graphic processing.. Mobile GPUs will need to see a huge leap in technology that my guess won't be coming for at least 10 years..
 
Last edited by a moderator:
So, Exophase, what would need to be in the Pandora 2 in order to run Dolphin fully?

It's a complex question. Part if it depends greatly on what game is being run, since games will have very different emulation loads. Part of it will depend on the skill and effort/time investment of the programmers. Part will really be unknown until it's tried.


I've only actually ever emulated two games on Dolphin. Both were Wii games, not Gamecube, but you can consider a Wii to be like a Gamecube overclocked 1.5x (both the CPU and GPU) with more/different memory. So the worst case emulation requirements would be around 1.5x too.


The first one I played completely on my 2.3-3.1GHz Ivy Bridge laptop. It ran full speed most but not all of the time, with frequent parts where it dipped down to around 80-90% or so and some parts where it went as low as 60% or so, IIRC. Since the music was emulated with HLE it stayed full speed so it wasn't as distracting, but it was still very obvious in the gameplay. The other game I played on my Sandy Bridge desktop (i5-2500K); although it's very slightly slower clock for clock I chose it over the laptop because its nominal clock was much higher and I could overclock it even further. But even at 4.5GHz it didn't play the game at full speed. The game only ran with LLE music which cracked below full speed, something I have little tolerance for.


This is a very small sample size so not very representative, and it's possible something about the emulator or my setup was much less than ideal (my desktop is running Linux, but so would a Pandora 2, if not Android). But I'm pretty confident that it's going to be a long time before we see ARM CPUs get anywhere close to my laptop or desktop, and unfortunately Gamecube/Wii emulation doesn't scale that much beyond 2 cores. You'd probably need at least a dual core Cortex-A15 at over 3.5GHz to start approaching the laptop's power, and there's no way you'll see such a thing available for Pandora 2.


Peak performance of ARM SoCs has scaled a tremendously in the last 5+ years, although like a lot of past periods of big computing growth this has also come at a cost of peak power consumption being much higher. But since peak power consumption is hitting its scaling limits for mobile platforms we're probably going to start seeing performance improvements slow down a lot. This is further hampered by manufacturing improvements slowing down outside and becoming much more expensive, and I'd hazard a guess that ARM themselves are slowing down their high end progress a bit. For instance, Cortex-A57 looks like it's going to be a more modest uarch shift than previous offerings have been, outside of the big ISA/64-bit move.
 
Last edited by a moderator:
For proper dreamcast, gamecube, even Wii gaming on the go,


you need John Doe's Portable Gaming Rig.


The JDPGR mechanism is considerably more powerful than a Pandora 1GHz.


I love my Pandora, but it simply can't compete with a blue-chip system like the JDPGR.

pandora%20alternative%20inspired%20by%20john%20doe%20from%20the%20blog.gif
 
Last edited by a moderator:
Back
Top