Add ppc64le/ppc64 architecture support MVP

[runlevel5]

Summary

Add build and runtime support for ppc64el (little-endian) and ppc64 (big-endian) POWER architectures. NaCl does not support PPC, so this ensures the engine builds cleanly and provides a clear error when NaCl is attempted on an unsupported platform.

CMake changes

• DaemonNacl.cmake: Add ppc64el/ppc64 case with dummy x86 NaCl defines (NaCl has no PPC support, but the defines are still needed for native builds)
• DaemonFlags.cmake: Add -mcpu=power8 (ppc64el) and -mcpu=power5 (ppc64) compiler flags via new GCC_GENERIC_CPU variable, since GCC on POWER uses -mcpu instead of -march/-mtune
• DaemonArchitecture.cmake: Define ppc64el_PARENT = ppc64 parent architecture relationship; add NACL_RUNTIME_ARCH allowlist and DAEMON_NACL_RUNTIME_ENABLED compile-time define that is only set when a NaCl loader exists for the target architecture (amd64, i686, armhf)

Runtime changes

• VirtualMachine.cpp: Add vm.nacl.available ROM cvar (true on amd64/i686/armhf, false otherwise) so the game UI can detect NaCl availability at runtime; add Sys::Error guard in VMBase::Create() if NaCl VM type is attempted on a platform without a NaCl loader

Usage on non-NaCl platforms

Dedicated server (sgame is not a CHEAT cvar):

./daemonded -set vm.sgame.type 3 +map plat23

Client (cgame is a CHEAT cvar, use -set to override before reset):

./daemon -set vm.cgame.type 3 -set vm.sgame.type 3 +devmap plat23

[slipher]

Without NaCl, it is impossible to join online matches. But the idea to build a partially-working version is fine. That way you can host servers (the native nexe VM type is recommended for that) and play single-player.

However the VM cvar type handling should work a bit differently. If you make the default value not NaCl, this results in confusing behavior when a player attempts to join an online match. The game would run, but everything would likely be messed up because the wrong client gamelogic is used. So instead of changing the default, exit with an error using Sys::Error advising that NaCl which is required for online games is not supported for this platform, but you can try setting the vm.cgame.type etc. cvars to 3.

[runlevel5]

However the VM cvar type handling should work a bit differently. If you make the default value not NaCl, this results in confusing behavior when a player attempts to join an online match. The game would run, but everything would likely be messed up because the wrong client gamelogic is used. So instead of changing the default, exit with an error using Sys::Error advising that NaCl which is required for online games is not supported for this platform, but you can try setting the vm.cgame.type etc. cvars to 3.

I like your proposal. I was thinking of giving a go at adding ppc64 support for NaCl but unsure if it is worth the effort taking into the fact it has been discontinued by Google.

[slipher]

I was thinking of giving a go at adding ppc64 support for NaCl but unsure if it is worth the effort taking into the fact it has been discontinued by Google.

I would recommend against trying that, since we are trying to get rid of NaCl and it would be an enormous undertaking.

[illwieckz]

I was thinking of giving a go at adding ppc64 support for NaCl

As slipher said, this is an enormous undertaking, and more precisely this requires:

• to implement the ppc64 support in the NaCl virtual machine using PPC64 intrinsics and other things,
• to implement nacl-ppc64 support in the Saigo branch of the LLVM compiler…

I do remind that not only we don't have an NaCl loader for PPC64, but we also don't have a compiler for NaCl on PPC64 as well. Implementing that is expected to be huge effort.

I actually wonder if qemu-user wouldn't be the shortest path to get NaCl running on something else than amd64/i686/armhf.

[runlevel5]

@slipher what's the best way to determine if a player is about to join an online game vs self-hosted / LAN game?

EDIT: nvm, I think the issue I am dealing with is how to pass on the params (vm.cgame.type etc) to the server when I choose to host local game

[runlevel5]

@illwieckz thanks for your feedback.

in theory it should be possible to add support of PPC64 for NaCl because some folks in the community has attempted to do so back in the day when Chromium was still on NaCl. So it's just a matter of digging up to see if the changes could be adapted or not. Cross-compilation from a x86_64 host is one of many ways to compile the codes for ppc64. Alternatively you could even apply for a native POWER8-based GitHub Action runner (ref: https://github.com/IBM/actionspz/issues).

[runlevel5]

@slipher I've just ran into a blocker, the Cvar::CHEAT will reset flags (even if -set vm.cgame.type 3 is specified explicitly for the client). This results in failure to host my own game locally because the flags get overridden

[illwieckz]

Yes, loading a non-NaCl game is a cheat. You can play locally using the +devmap <map> command, or enabling cheat in the server creation menu.

[illwieckz]

in theory it should be possible to add support of PPC64 for NaCl because some folks in the community has attempted to do so back in the day when Chromium was still on NaCl. So it's just a matter of digging up to see if the changes could be adapted or not.

That's interesting! But did it actually succeed?

Cross-compilation from a x86_64 host is one of many ways to compile the codes for ppc64.

You probably missed something very important there: there is no compiler producing ppc64 nexe binaries.

I'm not talking about a ppc64 compiler to build the nacl loader, neither about how to compile a ppc64 compiler.

NaCl runs native binaries, but built for the virtual machine. It is system-independent, not platform-independent. Without a compiler to build the NaCl game code for PPC64, a PPC64 NaCl loader has nothing to load.

[runlevel5]

That's interesting! But did it actually succeed?

I have to dig in and will let you know. Perhaps the amount of efforts would far outweigh the alternatives like WASM.

Yes, loading a non-NaCl game is a cheat. You can play locally using the +devmap command, or enabling cheat in the server creation menu.

Great to know. I am planning to add a ROM cvar engine.nacl.runtime or vm.nacl.available (or whatever convention you would like), this would give the UI (via Cvar.get("engine.nacl.runtime")) a way to know at runtime whether NaCl is available. I could make the Developer Mode option in Local Game Server hosting option opt-in and un-modifiable if NaCl is not present. For online game, it would die hard with errors that NaCl is not present. Thought?

[illwieckz]

I have mixed feelings about this.

I'm an obvious enthusiast in cross-platform stuff, I'm actually the one who made the game running on arm, on FreeBSD, and made it possible to build native games on platforms unsupported.

But while there can be an actual usage of running a native server whatever the platform, right now the multiplayer client cannot go online without running on x86 or arm.

So that seems to be a lot of work for being able to not play a multiplayer game the multiplayer way…

[illwieckz]

Since you're working on PPC support, you may want to reintroduce frsqrte.

We removed it because we could not test it. Here is the commit removing it: 2b7f64c.

If you want to reimplement frsqrte, don't revert that commit, to not reintroduce obsolete stuff around we don't need. It's better to do it like we did for _mm_rsqrt_ss, with some #if defined(DAEMON_ARCH_ppc64).

[slipher]

I have mixed feelings about this.

I'm an obvious enthusiast in cross-platform stuff, I'm actually the one who made the game running on arm, on FreeBSD, and made it possible to build native games on platforms unsupported.

But while there can be an actual usage of running a native server whatever the platform, right now the multiplayer client cannot go online without running on x86 or arm.

So that seems to be a lot of work for being able to not play a multiplayer game the multiplayer way…

I agree we don't want to have hundreds of lines of coded dedicated to something that is only marginally useful. But I think it's worthwhile if we do a minimal version without any unneeded bells and whistles. I suggest dropping the changes to default VM type values and the extra error message in cl_cgame.cpp, and keeping just the flags needed needed to build, the vm.nacl.available cvar and the Sys::Error upon trying to launch an NaCl VM.

If anyone wants to get into assembly micro-optimizations that can go in a separate PR.

[runlevel5]

Since you're working on PPC support, you may want to reintroduce frsqrte.

I will do it in a separate PR

[runlevel5]

While we are at it, I would like to invite both of you to the idea of using box64 emulator, I've developed a working PoC at #1946

[illwieckz]

While we are at it, I would like to invite both of you to the idea of using box64 emulator, I've developed a working PoC at #1946

Yes, I like that. This is kind of thing I meant when I said:

I actually wonder if qemu-user wouldn't be the shortest path to get NaCl running on something else than amd64/i686/armhf.

Though I just tried qemu-user, and while I can run some hello-world, that didn't worked with the gamecode for unknown reason. If box64 works that would be better.

[runlevel5]

@slipher I do not think I could remove the changes related to default VM type. So the issue is even +set vm.cgame.type 3 +devmap plat23 explicitly for example, the game doesn't work — the CHEAT reset puts it back to 0 before Create() runs. Hence the only way around this would be to change the default on non-NaCl platforms. Unless there are alternatives that I am not aware of.

[illwieckz]

The cheat stuff better be investigated separately.

The ”minimum viable product” would be a server running a map with devmap, then other things can be considered in other PRs after that.

[illwieckz]

Actually, did you try a ppc64 native server (daemonded) with map (not devmap) and then disabled cheat?

It's possible that the cheat thing you're seeing is client-specific.

If I'm right the server can run native code without cheats. But then only NaCl (non-cheat) clients can join.

[slipher]

@slipher I do not think I could remove the changes related to default VM type. So the issue is even +set vm.cgame.type 3 +devmap plat23 explicitly for example, the game doesn't work — the CHEAT reset puts it back to 0 before Create() runs. Hence the only way around this would be to change the default on non-NaCl platforms. Unless there are alternatives that I am not aware of.

Instead of +set, use -set vm.cgame.type 3 to ensure that the option is used from the very beginning. Note that the order matters: +.... must come at the end after any - options.

[runlevel5]

Instead of +set, use -set vm.cgame.type 3 to ensure that the option is used from the very beginning. Note that the order matters: +.... must come at the end after any - options.

@slipher yay! you are right. It works!

[runlevel5]

@slipher @illwieckz the PR is ready for review

[illwieckz]

Very nice. Not blocking, but we prefer doing if defined(A) than ifdef A, and then we don't need to add =1 to the definitions. We usually only set values to definitions when the value is actually used (for printing, for example).

[illwieckz]

That looks good!

For your knowledge, we have the usage to not merge things before 1 day has passed.

[illwieckz]

Thanks a lot @runlevel5! I'm now eager to see that box64 thing rebased. 🙂️