Author Topic: Porting games with a lot of x86 assembly to Dingoo  (Read 3311 times)

Rick_B

  • Guest
Porting games with a lot of x86 assembly to Dingoo
« on: September 10, 2011, 01:37:15 pm »
I noticed in the Ingenic documentation that the JZ4740 supports SIMD instructions. Since many early, non-hardware accelerated 3D games were written for x86 (using x86 assembly for the critical parts), how does this affect porting these games? Take a game like Descent for example, for which source code is available. There's plenty of x86 assembly code, so does that mean someone needs to pick through it and translate it to MIPS? And what if you want to take advantage of the SIMD capability of the CPU for a speed boost? Does the SIMD implementation on the JZ4740 resemble the x86 in any way?

cutterjohn

  • *
  • !
  • Posts: 397
Re: Porting games with a lot of x86 assembly to Dingoo
« Reply #1 on: September 10, 2011, 03:33:05 pm »
I noticed in the Ingenic documentation that the JZ4740 supports SIMD instructions. Since many early, non-hardware accelerated 3D games were written for x86 (using x86 assembly for the critical parts), how does this affect porting these games? Take a game like Descent for example, for which source code is available. There's plenty of x86 assembly code, so does that mean someone needs to pick through it and translate it to MIPS? And what if you want to take advantage of the SIMD capability of the CPU for a speed boost? Does the SIMD implementation on the JZ4740 resemble the x86 in any way?
I'll answer the x86 part, and you should already know this given what you wrote:  Yes x86 ASM WILL have to be ported to MIPS ASM somehow, either rewrite in MIPS ASM or a slower C routine compiled with the MIPS toolchain.  The two architectures are machine language incompatible and additionally use different ASM, it's the exact same thing that you'd see porting it to ARM or PowerPC...

SIMD: no idea.

mth

  • *
  • Posts: 298
Re: Porting games with a lot of x86 assembly to Dingoo
« Reply #2 on: September 11, 2011, 01:48:06 am »
And what if you want to take advantage of the SIMD capability of the CPU for a speed boost?
You have to write MIPS assembly for that using the MXU SIMD instructions. There are no intrinsics for these instructions (could be added though) and there is no auto-vectorization in the compiler.
Does the SIMD implementation on the JZ4740 resemble the x86 in any way?
Only in a very broad sense: both accelerate common vector operations, but the way they do it is quite different.

In any case, the first step in optimizing is always to figure out where the bottleneck is. Once you found this, you can try to write faster C code first. Often memory bandwidth is the bottleneck rather than raw processing power. If you find a bottleneck in the processing and the same computation is applied to different inputs, SIMD instructions might be the solution.

pcercuei

  • ***
  • Posts: 1427
    • My devblog
Re: Porting games with a lot of x86 assembly to Dingoo
« Reply #3 on: September 11, 2011, 01:56:35 am »
It has to be noted that the jz4740 MXU (SIMD) instruction set does not provide logical instructions (AND, OR...) nor it provides instructions for bit shifts; so the use of the MXU is quite limited to arithmetical calculations, which can still be useful for audio or video decoding.

Rick_B

  • Guest
Re: Porting games with a lot of x86 assembly to Dingoo
« Reply #4 on: September 11, 2011, 04:37:58 pm »
I have a sneaking suspicion that the reason a lot of open source emulators (psx4all, etc) run crappy on the Dingoo is because they are not optimized for its CPU. I checked out psx4all, and it seemed to be optimized for ARM (at least as far as any obvious hardware optimizations go). Of course, C/C++ for an emulator like this would be fine for a desktop machine, since optimization isn't as critical due to the adequate CPU power (relative to the PSX's CPU, the same might be said for fast ARM chips). However, for a machine like Dingoo I'd think you'd need to use every optimization you could to get decent performance. Vectorizing some of the code might be a solution as we discussed. I don't know how attractive this is, considering the lifespan of the Dingoo isn't clear. But PSX emulation should be an ongoing project from now until the end of time, if only for archival and research purposes.

cutterjohn

  • *
  • !
  • Posts: 397
Re: Porting games with a lot of x86 assembly to Dingoo
« Reply #5 on: September 11, 2011, 06:50:52 pm »
I have a sneaking suspicion that the reason a lot of open source emulators (psx4all, etc) run crappy on the Dingoo is because they are not optimized for its CPU. I checked out psx4all, and it seemed to be optimized for ARM (at least as far as any obvious hardware optimizations go). Of course, C/C++ for an emulator like this would be fine for a desktop machine, since optimization isn't as critical due to the adequate CPU power (relative to the PSX's CPU, the same might be said for fast ARM chips). However, for a machine like Dingoo I'd think you'd need to use every optimization you could to get decent performance. Vectorizing some of the code might be a solution as we discussed. I don't know how attractive this is, considering the lifespan of the Dingoo isn't clear. But PSX emulation should be an ongoing project from now until the end of time, if only for archival and research purposes.
Actually psx4all SHOULD run BETTER on the A320 as it's also MIPS based and only needs trapping for functions that it doesn't directly support that the PSX did(if any), and any co-procs which still would have to be emulated.  The only other thing slowing it would be the lack of any kind of GPU as even the PSX did have some limited 3D/2D hw.

But all of that yep, I'm in the ARM camp for a newer handheld as there is just so much more likelihood of getting useful pre-optimized ASM for emulators given that pretty much all phones and tablets are ARM11 or better based, plus all the recent ARM based SoCs all come with a 3D GPU onboard.  i.e.  I really doubt that anyone would be much interested in learning MIPS arch/ASM to really optimize code when MIPS just simply isn't used in much any longer, ARM just has more potential for general usefulness ATM (esp. now since Android supports native machine language execution now).

fpsece(a paid Android PSX emulator, also wince hence the "ce") works pretty well on my 1GHz MSM8655/Adreno 220 based phone and on my Tegra 2 tablet.  It also worked OK on a 600MHz MSM7627/Adreno 205 based phone.  The only that kinda sucks are no controls unless you use bluetooth and a wiimote or other compatible bt controller.  Oh, and the GPU's not really helping fpsece out much ATM as the author has turned OpenGL support live yet on release builds.  Of course turning on OpenGL is likely to cause all sorts of problems given the range of GPUs in ARM SoCs: Adreno(formerly ATI), MALI(ARM's own GPU), nVidia ULP, PowerVR SGX, etc. and any little bugs that might be triggered in the GPUs.

Rick_B

  • Guest
Re: Porting games with a lot of x86 assembly to Dingoo
« Reply #6 on: September 12, 2011, 02:59:38 am »
Oh, and the GPU's not really helping fpsece out much ATM as the author has turned OpenGL support live yet on release builds.  Of course turning on OpenGL is likely to cause all sorts of problems given the range of GPUs in ARM SoCs: Adreno(formerly ATI), MALI(ARM's own GPU), nVidia ULP, PowerVR SGX, etc. and any little bugs that might be triggered in the GPUs.
Isn't OpenGL ES supposed to be part of the Android spec? Aren't all CPUs supposed to support it one way or another?

pcercuei

  • ***
  • Posts: 1427
    • My devblog
Re: Porting games with a lot of x86 assembly to Dingoo
« Reply #7 on: September 12, 2011, 01:09:48 pm »
Actually psx4all SHOULD run BETTER on the A320 as it's also MIPS based and only needs trapping for functions that it doesn't directly support that the PSX did(if any), and any co-procs which still would have to be emulated.  The only other thing slowing it would be the lack of any kind of GPU as even the PSX did have some limited 3D/2D hw.
You can't do that. There's a good reason why the PSP emus use a JIT recompiler on the PSP (which is MIPS based).

Instead, what IMHO could be done is a static recompilation of the binary, I know JayFoxRox did attempt that for his PSP emulator. But that's an enormous task and compatibility would nosedive.
« Last Edit: September 12, 2011, 01:11:33 pm by Ayla »

cutterjohn

  • *
  • !
  • Posts: 397
Re: Porting games with a lot of x86 assembly to Dingoo
« Reply #8 on: September 14, 2011, 03:55:09 pm »
Oh, and the GPU's not really helping fpsece out much ATM as the author has turned OpenGL support live yet on release builds.  Of course turning on OpenGL is likely to cause all sorts of problems given the range of GPUs in ARM SoCs: Adreno(formerly ATI), MALI(ARM's own GPU), nVidia ULP, PowerVR SGX, etc. and any little bugs that might be triggered in the GPUs.
Isn't OpenGL ES supposed to be part of the Android spec? Aren't all CPUs supposed to support it one way or another?
Yes it is, and all recent SoCs have GPUs that support OpenGL 1.1, OpenGL ES 1.0 & 2.0, but the devs of fpsece haven't(to their satisfaction) gotten GL support good enough for release builds(according to their forums). Probably will be GPU specific bugs as well, as I intimated before... still it works very well w/o having enabled 3D hw support.

MIPS: problem being that I haven't really looked at the PSX hw in quite some time, nor really the A320's yet either, I'm just really in the mindset camp of MIPS(very much like PowerPC) is pretty much a deadend, i.e. waste of time and would MUCH rather work on something ARM or x86 based which show no signs of dieing off anytime soon. I don't do emulators either, so I've really only a very light and passing interest in console hw, i.e. not much beyond evaluating their potential performance/usefulness.  (It's why I've decided to skip the nanonote, along with the fact that lacks WiFi, pretty much useless to me other than as a lesser A320 with a kb.)

[EDIT]
PSP:  Didn't they include the PSX CPU as a support chip like they did on the PS2? (IIRC)
[/EDIT]
« Last Edit: September 14, 2011, 03:57:16 pm by cutterjohn »

 

Post a new topic
Post a new topic