search

libretro / mupen64plus-libretro-nx

Improved mupen64plus libretro core reimplementation
GNU General Public License v2.0
230 stars 114 forks source link

Fix other Platforms #11

Closed m4xw closed 5 years ago

m4xw commented 5 years ago

Functional:

Notes: Some changes for awk are needed across all platforms and Android doesn't generate the header properly yet (works if pre generated) These could be generated and committed, but this might cause Issues with different toolchain versions being used.

"mupen_next" is our master branch for the time being

[More infos added later on...]

IntelMiner commented 5 years ago

Pulled from bug report in other repository

I managed to build Retroarch + Mupen64 from git on an RPi 3, with the "use new vendor library" patches @m4xw requested I test

However running it seems to crash upon loading a game

The last lines of the output log are 

[INFO] [GL]: Found GL context: kms
[INFO] [GL]: Detecting screen resolution 1366x768.
[INFO] [EGL] Found EGL_EXT_platform_base, trying eglGetPlatformDisplayEXT
[INFO] [EGL]: EGL version: 1.4
[ERROR] [EGL]: #0x3009, EGL_BAD_MATCH
[ERROR] [Video]: Cannot open video driver ... Exiting ...
[ERROR] Fatal error received in: "init_video()"

Annoyingly looking up #0x3009, EGL_BAD_MATCH or eglGetPlatformDisplayEXT seem to bring up either source code, or Android development posts

The full RetroArch debug output is attached below as well

crash.log

IntelMiner commented 5 years ago

Looking things over. I may have grabbed the wrong end of the wrong stick, compiling Mupen64 from the upstream libretro repository, instead of the mupen64-libretro-nx fork

I'll rebuild the nx core fork over the weekend and report back

m4xw commented 5 years ago

Yea back then I wanted you to test normal mupen. We focus on m64p-next now, try first without the patch (its not in next yet) and then with. If the patch breaks it for you, you probably don't have your system up2date.

Try apt-get update && apt-get dist-upgrade && rpi-update (or was it raspi-update?) -> reboot

IntelMiner commented 5 years ago

I've got the latest firmware and the 4.14 kernel all ready to go, so that's all done and dusted

Just waiting for the weather to let me jump back in to tinkering

m4xw commented 5 years ago

@IntelMiner Heh, you get burned, I get frozen.

hhromic commented 5 years ago

@m4xw perhaps entries in the libretro-super recipes can be added for the confirmed platforms that are working? i.e. arm7neonhf and linux-x64-generic, so the buildbot can start generating builds for those?

Edit: in coming days I can try libretro-super for arm7neonhf so we are sure to submit a PR there.

m4xw commented 5 years ago

@hhromic Thats the plan, but currently there seems to be a regression that I need to deal with first (hence why I just had to revert my changes)

IntelMiner commented 5 years ago

Built the current trunk of this repository and loaded it into RetroArch

Crashed on loading a ROM again

Attached crash log looks to be the same as the one from the upstream libretro tree

Crash2.txt

m4xw commented 5 years ago

@IntelMiner do you build with make platform=unix or make platform=rpi ?

IntelMiner commented 5 years ago

@m4xw Just a standard make -j4

m4xw commented 5 years ago

@IntelMiner That wont work. Pretty sure that will default to unix. Use make platform=rpi

hhromic commented 5 years ago

@IntelMiner I don't face any crashes when I tested on Raspberry Pi on a standard Stretch installation. Try using platform=rpi3. If still no luck, can you try this make invocation?

make platform=rpi3 WITH_DYNAREC=arm HAVE_NEON=1 FORCE_GLES=1

Maybe the last bit helps.

Edit: as @m4xw suggests, using just rpi also should work, I'm just too used to provide rpi3 :)

IntelMiner commented 5 years ago

I'll give that a shot and report back shortly

IntelMiner commented 5 years ago

make platform=rpi3 WITH_DYNAREC=arm HAVE_NEON=1 FORCE_GLES=1

This one immediately fails with

c++: error: unrecognized command line option '-mvectorize-with-neon-quad'
c++: error: unrecognized command line option '-mfpu=neon-fp-armv8'
c++: error: unrecognized command line option '-mfloat-abi=hard'

It looks like those are only valid for 32-bit "AARCH32" instructions, according to this post

ARMv8 implies 32-bit code (aarch32). Aaarch64 implies 64-bit code. These are two different compilers, with two different sets of command line options.

Building with just make platform=rpi3 gives the same results. Might be worth flagging the Pi 3 specifically as an ARM64 target as well?

make platform=rpi eventually dies with a wall of compiler errors, starting at

mupen64plus-core/src/device/r4300/new_dynarec/arm/assem_arm.c:68:3: error: initializer element is not computable at load time
mupen64plus-core/src/device/r4300/new_dynarec/arm/assem_arm.c:68:3: note: (near initialization for 'jump_vaddr_reg[0]')
mupen64plus-core/src/device/r4300/new_dynarec/arm/assem_arm.c:69:3: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
   (int)jump_vaddr_r1,
   ^

make rpi.txt

hhromic commented 5 years ago

@IntelMiner what exactly is your build environment? I built the core successfully on first try with a standard Raspbian Stretch Lite image, which is 32 bits.

IntelMiner commented 5 years ago

@hhromic I'm using a Gentoo ARM64 setup.

It shouldn't be any different except for being completely 64-bit, AFAIK there's no multi-lib for ARM platforms?

hhromic commented 5 years ago

Ahh I see. The platform=rpi targets only 32 bits systems, so probably the Makefile will need fine-tuning for providing the right flags for 64 bits on rpi platform. Perhaps a new rpi64 definition is better suited. Anyway, I have zero experience on building for ARM64 so unfortunately I can't be of more help there :(

Edit: I also suspect that in ARM64 the videocore drivers from the RPI foundation don't work and instead you are using KMS drivers for GLES. Probably that also needs fine-tuning for building. I don't think it is that straight-forward, but I might be wrong :)

IntelMiner commented 5 years ago

Thumbing through the Makefile, it looks like the CFLAGS for rpi3 are set to

-march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard

Pruning that back to just -march=armv8-a+crc -mtune=cortex-a53 should work for ARM64

I also adjusted the WITH_DYNAREC=arm to WITH_DYNAREC=aarch64

Rebuilding after that gave an immediate

c++: error: unrecognized command line option '-mvectorize-with-neon-quad'

Looking that error up shows it seems to be included in ARM64 by default, so I removed that from the flags list

Doing a make platform=rpi3 after making those edits seems to get a lot further, eventually erroring out, starting at

<command-line>:0:4: error: expected identifier before numeric constant
mupen64plus-core/src/device/r4300/new_dynarec/arm64/assem_arm64.c:42:3: note: in expansion of macro 'VC'
   VC,
   ^~

arm64-build.txt

hhromic commented 5 years ago

I can confirm that the build for Raspberry Pi (Raspbian 32 bits) requires either platform=rpi2 or platform=rpi3 according to the device used. Using just rpi won't work because the assembler linkage requires a specific CPU to be passed to the compiler, which is not set with platform=rpi, defaulting to a CPU that doesn't support required ASM instructions. Note that mupen64plus doesn't work well on a RPI1 device anyway, so IMHO is not worth adding the armv6 CPU flags for rpi.

IntelMiner commented 5 years ago

It might be worth just dropping the "Original" RPi entirely, I believe it's only ARMv6 anyway

Perhaps something like if rpi=2 use ARMv7 and if rpi=3 use ARM64 could be done? Or rpi3-64 or the like

The edits I made to the Makefile got quite far in the build process, before hitting the ASM errors that you mentioned. I'm not sure how much more work it would be to "add" the Pi 3 as an ARM64 target beyond that though

m4xw commented 5 years ago

@IntelMiner "VC" is part of a enum and on the raspberry platform its a define so that fucks stuff up.

typedef enum { EQ, NE, CS, CC, MI, PL, VS, VC,<--- HI, LS, GE, LT, GT, LE, AW, NV } eCond;

m4xw commented 5 years ago

It needs some little changes in the dynarec, me and Gillou will deal with it.

IntelMiner commented 5 years ago

My shitty external hard drive kicked the bucket. So I wont be able to test builds for another week or two

Keep me posted though

m4xw commented 5 years ago

Lol. Sure thing.

hhromic commented 5 years ago

It might be worth just dropping the "Original" RPi entirely, I believe it's only ARMv6 anyway

I don't think the original RPi was ever supported at all :) And yes it's armv6. The conditionals in the Makefile seem to be designed to only properly handle rpi2 and rpi3, with rpi used just to perform common stuff for these two, not to support the RPI1.

Perhaps something like if rpi=2 use ARMv7 and if rpi=3 use ARM64 could be done? Or rpi3-64 or the like

I don't think rpi3 alone should be used for ARM64 because that platform target is used for building mainly in Raspbian Stretch (32 bits) with the closed-source graphics userland. I would advocate either for creating a new rpi64 target (easier to maintain) or to create more logic to set flags inside rpi3 according to $(ARCH) (more complicated and error prone). But never replace rpi3 to build only for ARM64.

I still am skeptical how the graphics would work in ARM64 because of the "official" VC4 userland driver being available only for 32 bits at this point. Probably it works with the open source VC4 driver, which I'm not sure is mature enough for N64 emulation. I guess there is a lot of testing on the road :) I should have more time in some months to setup my own 64 bits env for testing, sorry I can't help more at the moment :(

hhromic commented 5 years ago

@m4xw btw, in the OP : (potentially x86 too, need verification) should be addressed now :) Edit: at least for building as I can't test the core in gameplay for x86 at the moment. But if/when the buildbot generates binaries, other users can test.

m4xw commented 5 years ago

@hhromic Thanks, I will check that (still have to PR the super recipes btw). I am kinda busy with reversing the new fw update for the Switch (7.0 dropped yesterday) and also dayjob. Your help is appreciated a lot, if you have discord feel free to join https://discord.gg/Vv6tKt7 That way we could coordinate things better if needed.

Edit: Oh just saw it, forgot to remove

IntelMiner commented 5 years ago

@hhromic I can't find much information on the state of the open drivers versus the old "closed" ones. It's a shame the Ras Pi foundation wont give us ARM64 versions of the relevant libraries. Though in the long run, an open driver is definitely a better bet

Glass half full though. Perhaps having a "killer app" like that for the Pi would just spur more people to tackle the buggy driver :P

hhromic commented 5 years ago

@m4xw thanks for the invitation, hopefully I have more time in coming months :) @IntelMiner I saw there are basically two distro options currently for RPI3-64: Arch64 and Gentoo64. The second one seems to be more actively maintaned and explicitly claims to support hardware accelerated video using the vc4-kms-v3d driver. So it looks like this is the key to investigate more: https://wiki.gentoo.org/wiki/Raspberry_Pi_VC4

On a side note, I saw that @m4xw added the new recipes to the buildbot \o/ However, unfortunately the arm7neonhf target is failing. The reason is that there are missing dependencies in the buildbot environment: -lz -lpng -lGL. On my local test I had these libraries already installed so I didn't notice they were missing. For the record, the old mupen64plus core is also failing with the same dependencies missing, except libpng because it used to be integrated in the codebase.

I don't know how the buildbot environment is setup for each target, so I will have to investigate more unless any of you guys have some more technical information? In the meantime I will try to take a look in other cores using OpenGL/PNG/zlib and don't embed them in the codebase for the armv7 target and see how they do it

Log: mupen64plus_next: [status: fail] [recipes/linux/cores-linux-arm7neonhf] LOG: http://p.0bl.net/86607

m4xw commented 5 years ago

@hhromic yea I am aware of that, it's a Issue with the setup. I will need to figure smth out.

hhromic commented 5 years ago

parallel-n64 and 3dengine are also failing with missing dependency for -lGL. This means all the cores in the recipes for armv7 that use GENERIC_GL are failing currently. Def this means some adjustment in the buildbot environment in general, not just for mupen.

m4xw commented 5 years ago

@hhromic correct. I don't consider this Issue caused by you. ;)

hhromic commented 5 years ago

Thanks, I wasn't trying to defend myself in any case :) Just trying to find where is the problem to hopefully fix it for real :) Probably needs to be escalated to whoever is the maintainer of the buildbot.

IntelMiner commented 5 years ago

@hhromic The Gentoo VC4 Wiki page looks like it hasn't been updated since June 2017, initially being created in August of 2016

It looks like it wants to pull in sys-boot/raspberrypi-firmware which appears to have a package code of 20160309 (I believe that's the "version" of the firmware it'll fetch. Though I haven't tried pulling the package in)

The package itself hasn't been maintained since September of 2017 and looks to be ARMv7 only (keyworded to ~arm in Gentoo, not ~arm64)

Irritatingly, according to this there's no intention to add ARM64 blobs for the VC4. An open source driver is our only option

I'll go ahead and get that updated on Gentoo's wiki just to clear things up there

There is also a page for Debian ARM64 on the RPi3 available here along with a "preview" image that seems to work quite well, last updated on December 4th, 2018

I built RetroArch on the Debian image a couple weeks ago during testing, just to rule out Gentoo as the source of the GL issues I posted about and it did seem to fail in the same way, so it should work fine for testing/building on

hhromic commented 5 years ago

@IntelMiner indeed last night I also found out about that updated Debian ARM64 effort and was going to comment here today. To me that option is very interesting because I'm a Debian user myself, so feeling very "at home" with that. Looking forward to try that one soon. Is good we are gathering some resources in the meantime.

@m4xw I posted now an experimental scriptmodule to build/configure/install mupen64plus-next in any standard RetroPie system in the RP forum. Hopefully some users can start to use it easily and provide feedback for future improvements.

m4xw commented 5 years ago

@hhromic Can you link it here? I am curious.

hhromic commented 5 years ago

sorry forgot to add the link, I was planning on doing so :D https://retropie.org.uk/forum/topic/21093/lr-mupen64plus-next-experimental-scriptmodule-for-testing

Let me know if you want to change anything.

IntelMiner commented 5 years ago

@hhromic ARM64 in Debian looks to be a lot more first class than Gentoo at the moment. Lots of packages in Gentoo are "keyworded" (stuck in testing) due to lack of users. I might switch over if that build I linked works well for you, just to save myself some headaches

m4xw commented 5 years ago

@IntelMiner the VC issue should be resolved.

IntelMiner commented 5 years ago

Will test when I can and report back

hhromic commented 5 years ago

Guys, there is a user in the RP forums that is trying the old core on ODROID XU4. Currently we are sorting out compilation errors and then will instruct to test this new core. Hopefully we soon can add a new supported platform :)

m4xw commented 5 years ago

fwiw Gillou developed the aarch64 dynarec on a odroid ;)

hhromic commented 5 years ago

We sorted it out now, the user was missing the opengl libs and the Makefile requires a minor update. I'm directing now to try this core and send a PR with the Makefile fix if all goes well !

hhromic commented 5 years ago

@m4xw I can confirm now that the core is building for ODROID XU4 devices too using Ubuntu minimal, and probably XU3 too because it has the same CPU ;)

VGkav commented 5 years ago

I'd like to use this on my Playstation Classic

Will a build eventually appear on: https://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/

?

hhromic commented 5 years ago

@AnotherLife , yes it will. Actually the core is building fine for armv7-neon-hf locally, it is just that the libretro buildbot needs minor configuration to restart the builds, but haven't been done yet. You will have to be a bit patient.

BananaRama203 commented 5 years ago

@AnotherLife @hhromic I am adding the classic build to the deployment today. Ideally where possible you want to use the ones specifically used for the PSC as we don't actually compile for A7A7 for the PSC and tune it to A8A35.

This reminds me I need to add the classic platforms and default config changes.

hhromic commented 5 years ago

@swingflip sounds good ! the Makefile in this core needs to be updated to support the classic platform explicitly right?

BananaRama203 commented 5 years ago

@hhromic yeah and IIRC there are some other values that needed to be changed for the lower end hardware too like texture cache size etc.

We really need to replace the armv7-neon-hf with the classic ones once I get chance to properly sort out the platform

BananaRama203 commented 5 years ago

@hhromic @AnotherLife

PSC: https://classicmodscloud.com/classic_libretro/stable/classic_armv8_a35/mupen64plus_next_libretro.so (armv7 Cortex A7 HF NEON)

(S)NESC: https://classicmodscloud.com/classic_libretro/nightly/classic_armv7_a7/2019-02-08/so/mupen64plus_next_libretro.so (armv8 Cortex A35 HF NEON) (This is today's nightly build)