Co-Processor Hardware accelerator

[bentomo]

Hey guys, long time dolphin fan here.

So I mostly have a hardware background, microcontrollers, pcbs, fpgas, etc. And I'm just starting to get into ARM. I'm actually from the portablizers forum where we cut up gamecube and wii boards and make portables out of them.


I'm wondering if there's some kind of bottleneck on android that can be solved with a hardware accelerator.

What I mean to say is take something like an ARM SOM

https://www.intrinsyc.com/computing-platforms/intrinsyc-open-q-805-system-module/ for example

Attach a high end FPGA (hardware programmable chip) via the pcie bus, and pipeline some of the interpreter instructions through there and back to the gpu for rendering.

My thought is to have a complete circuit board that can portably and reliably run gamecube games. The best we have so far on the portablizer scene is cutting up a Wii mobo or desoldering the chip and moving it to a custom board. This process just sucks because the wii is still power hungry compared to most ARM chips and cutting boards and reballing processors is a huge amount of effort to reproduce.

Thoughts?

[Nintonito]

(02-14-2017, 11:17 AM)bentomo Wrote: Hey guys, long time dolphin fan here.

So I mostly have a hardware background, microcontrollers, pcbs, fpgas, etc. And I'm just starting to get into ARM. I'm actually from the portablizers forum where we cut up gamecube and wii boards and make portables out of them.


I'm wondering if there's some kind of bottleneck on android that can be solved with a hardware accelerator.

What I mean to say is take something like an ARM SOM

https://www.intrinsyc.com/computing-platforms/intrinsyc-open-q-805-system-module/ for example

Attach a high end FPGA (hardware programmable chip) via the pcie bus, and pipeline some of the interpreter instructions through there and back to the gpu for rendering.

My thought is to have a complete circuit board that can portably and reliably run gamecube games. The best we have so far on the portablizer scene is cutting up a Wii mobo or desoldering the chip and moving it to a custom board. This process just sucks because the wii is still power hungry compared to most ARM chips and cutting boards and reballing processors is a huge amount of effort to reproduce.

Thoughts?

You'd need to also be coding an android build with a ton of security features disabled that allows direct issues of commands like that. You'd also need to heavily modify dolphin. I don't doubt you couldn't do this in theory, but you would need manpower.

[Sonicadvance1]

...You wouldn't need an Android build with "a ton of security features disabled." You'd just need to set up permissions properly to allow access to the device.
Depending on situation and device Dolphin will be GPU emulation limited((Likely on Mali, Adreno, & PVR devices), or CPU emulation limited(Most likely). Pushing this work off on to an FPGA is something that I'm unsure if a a consumer viable FPGA board would be able to handle.
Also the latencies of communicating to an FPGA may be killer.

Dolphin also needs to emulate the DSP of the original NGC/Wii which is typically HLE'd, but can be LLE'd. HLE emulation of this is fairly low cost, but if someone was wanting to do a fun project they could implement an LLE implementation of the DSP emulation via a JIT. Either a JIT on the CPU, JIT on the Qualcomm Hexagon, or possibly running on some FPGA.
Again no idea if a consumer viable FPGA could handle something like the DSP, I've never played with FPGAs and I don't know what their performance limitations are.

[mimimi]

What about taking the fastest arm cpu available and attaching a proper (mobile?) gpu to it? This should get past the gpu and gpu driver problems, "only" leaving the cpu problem.

[antarusch]

(02-15-2017, 12:45 AM)Sonicadvance1 Wrote: ...You wouldn't need an Android build with "a ton of security features disabled." You'd just need to set up permissions properly to allow access to the device.
Depending on situation and device Dolphin will be GPU emulation limited((Likely on Mali, Adreno, & PVR devices), or CPU emulation limited(Most likely). Pushing this work off on to an FPGA is something that I'm unsure if a a consumer viable FPGA board would be able to handle.
Also the latencies of communicating to an FPGA may be killer.

Dolphin also needs to emulate the DSP of the original NGC/Wii which is typically HLE'd, but can be LLE'd. HLE emulation of this is fairly low cost, but if someone was wanting to do a fun project they could implement an LLE implementation of the DSP emulation via a JIT. Either a JIT on the CPU, JIT on the Qualcomm Hexagon, or possibly running on some FPGA.
Again no idea if a consumer viable FPGA could handle something like the DSP, I've never played with FPGAs and I don't know what their performance limitations are.

Also the SOC is based on the 805 snapdragon and only supports 32 bit, dolphin is 64 bit only, even with this it would be feasible?

[bentomo]

(02-15-2017, 12:45 AM)Sonicadvance1 Wrote: ...You wouldn't need an Android build with "a ton of security features disabled." You'd just need to set up permissions properly to allow access to the device.
Depending on situation and device Dolphin will be GPU emulation limited((Likely on Mali, Adreno, & PVR devices), or CPU emulation limited(Most likely). Pushing this work off on to an FPGA is something that I'm unsure if a a consumer viable FPGA board would be able to handle.
Also the latencies of communicating to an FPGA may be killer.

Dolphin also needs to emulate the DSP of the original NGC/Wii which is typically HLE'd, but can be LLE'd. HLE emulation of this is fairly low cost, but if someone was wanting to do a fun project they could implement an LLE implementation of the DSP emulation via a JIT. Either a JIT on the CPU, JIT on the Qualcomm Hexagon, or possibly running on some FPGA.
Again no idea if a consumer viable FPGA could handle something like the DSP, I've never played with FPGAs and I don't know what their performance limitations are.

There are some pretty snappy consumer FPGA's out there, for example, if you only do a small amount of logic and force it to only exist in the I/O block you can get some pretty quick combinational logic out of it. Somewhere around the nanosecond range. I think the real limitation is getting the data out of a consumer based ARM chip. Fitting a whole gpu on an FPGA wouldn't work as they're too small even for the high end ones, but if I can implement a combinational logic interpreter and feed that back to the ARM gpu then we might be able to see a significant speed improvement. The DSP sounds like it could be implemented on an FPGA as well, is the DSP on the GC/Wii another bottleneck in emulation?

Realistically I was looking at the Dragonboard 410, which is obviously very underpowered for dolphin but implementing some LLE could be really handy depending on the speed at which I can pull data off of the board. The only problem is it only lists it's high speed interfaces for displays. I'm not sure how much control I have over this I/O. 

My question is probably: Where should I start looking at for Dolphin on Android. Obviously I could just start combing through the git repository but that's a bit overwhelming. 

(02-15-2017, 12:54 AM)mimimi Wrote: What about taking the fastest arm cpu available and attaching a proper (mobile?) gpu to it? This should get past the gpu and gpu driver problems, "only" leaving the cpu problem.

The problem is getting a decent mobile gpu in the first place, let alone on consumer level. These chips are usually only sold to laptop vendors in mass quantities. The closest you'll find for development is probably something like the Jetson board or nvidias $500 TX1 dev board. And you'll probably run into the same driver issues as before.

(02-15-2017, 01:24 AM)antarusch Wrote: Also the SOC is based on the 805 snapdragon and only supports 32 bit, dolphin is 64 bit only, even with this it would be feasible?

I was just using that as an example. I'd probably use a dragonboard 410 and try to boost it's throughput with an external accelerator.

[degasus]

We usually have two hot spots in dolphin: Emulating the main CPU, and the GPU. The DSP is really cheap because of HLE, and a LLE will always be slower - just more accurate.

For a FPGA as CPU: I fear the latency might kill this idea. There are a few instructions which doesn't match ARM well (~50 instructions), but they are in total lower than 100k/s. So they aren't that heigh on profile, but the latency requirements for a FPGA implementation will be very high. If you want to do anything in the FPGA, I'd recormend the whole PPC here. But this will be a very big effort, and the outcome might be surprisingly bad. You will also need very fast memory accesses, a floating point ALU, and everything at at least 500 MHz.

FPGA is GPU is already handled well here. Too big to fit on a FPGA... Also, as you want to target the db410c, freedreno supports everything we need for a fast GPU emulation.

Neverless, a few links here. The main android part is in here. But this is likely not what you're looking for. This is the android GUI
https://github.com/dolphin-emu/dolphin/tree/master/Source/Android/app/src/main/java/org/dolphinemu/dolphinemu

If you're looking for the ARM part, which is unrelated to Android. This is the big performance bottleneck on android right now:
https://github.com/dolphin-emu/dolphin/tree/master/Source/Core/Core/PowerPC/JitArm64

I'd checkout the last link. But don't expect to get any game fullspeed on the db410c. It's a low-clocked A53 CPU. My shield with its A57@2GHz is too slow for most games :/

Or just also wait for the dragonboard 820c....

[retroben]

Would it even be feasible to replace the A57 chipset with the highest-end MediaTek ARM CPU chipset into a Shield TV?
That extra nudge would probably make performance a lot better if it could be done reasonably enough for more Ghz,a larger IPC rate and better power optimizations.

The interesting thing is that on every upgrade,they have the pre-decessors as low-powered cores alongside with it to work around overheating and energy consumption.

[Helios]

SoC means system on a chip. Everything in one package. You can't swap out the CPU or GPU on a SoC without redesigning the entire thing.