At present, the emulation code of gpSP is wrapped with libco. This PR adds a new compile-time option (USE_LIBCO) which can be disabled to instead use a pthreads-based mechanism.
Why would we want such a thing?
1) libco is fine, but can cause strange and unpredictable behaviour when used with code not specifically designed around it
2) We simply don't have working libco implementations for all platforms. A notable example is OpenDingux - attempting to use libco on OpenDingux causes the instant death of the process...
From basic testing using RetroArch's fast forward feature, I see a performance decrease when using the pthreads-based mechanism of ~7%. USE_LIBCO is therefore set to 1 on all platforms apart from OpenDingux, where it is absolutely required.
I should make it very clear that the pthreads-based mechanism is entirely the work of @realnc, lifted from here: https://github.com/libretro/libretro-uae/pull/224. Many, many thanks to him for this splendid code :)
Since this PR fixes the OpenDingux build, a note on performance: even though we have to use the interpreter, on an RG350M a large number of games run at full speed with colour correction enabled and the Grid2x video filter. This is quite impressive. Once I fix the automatic frameskip option, it will be a viable core on this platform.
And a secondary note: We do have a MIPS dynarec, and I managed to build it for OpenDingux by adding some compatibly macros - but sadly, the MIPS assembly is not PIC compliant, and cannot be linked into a shared object library. It is apparently possible to convert the assembly to use relative addresses, but this is far beyond me. So we're stuck with the interpreter for the time being...
At present, the emulation code of gpSP is wrapped with libco. This PR adds a new compile-time option (
USE_LIBCO) which can be disabled to instead use a pthreads-based mechanism.Why would we want such a thing?
1) libco is fine, but can cause strange and unpredictable behaviour when used with code not specifically designed around it
2) We simply don't have working libco implementations for all platforms. A notable example is OpenDingux - attempting to use libco on OpenDingux causes the instant death of the process...
From basic testing using RetroArch's fast forward feature, I see a performance decrease when using the pthreads-based mechanism of ~7%.
USE_LIBCOis therefore set to1on all platforms apart from OpenDingux, where it is absolutely required.I should make it very clear that the pthreads-based mechanism is entirely the work of @realnc, lifted from here: https://github.com/libretro/libretro-uae/pull/224. Many, many thanks to him for this splendid code :)
Since this PR fixes the OpenDingux build, a note on performance: even though we have to use the interpreter, on an RG350M a large number of games run at full speed with colour correction enabled and the Grid2x video filter. This is quite impressive. Once I fix the automatic frameskip option, it will be a viable core on this platform.
And a secondary note: We do have a MIPS dynarec, and I managed to build it for OpenDingux by adding some compatibly macros - but sadly, the MIPS assembly is not PIC compliant, and cannot be linked into a shared object library. It is apparently possible to convert the assembly to use relative addresses, but this is far beyond me. So we're stuck with the interpreter for the time being...