Apple Silicon Support

[sampottinger]

Following up in conversation from the forums, just flagging that we will probably need to jump forward in the Java 11 build chain or to JDK 14+ to get http://openjdk.java.net/jeps/8251280 to continue to support mac and, depending on how it is supported, we may need two builds for Mac moving forward. Re OpenJFX: https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-July/026960.html. I don't see any issues with fast forwarding even if we need to go to JDK 14+ but it will take just a little testing.

I know this is the Processing 4 repo but it's worth noting that, per conversation at adoptium/temurin-build#1922, it's still unclear what this will look like for Java 8.

[benfry]

Jump forward meaning 11.0.8? Or that we need to continue updating past that once the JEP is available? Or something else I'm missing?

Apple Silicon would also be another vote for LWJGL, since the move will almost assuredly require a Metal backend, which LWJGL may either have working (is it via bgfx?) or is at least considering.

I'd be willing to bet we won't see JOGL running on ARM Macs for a bit, if at all. It's a ton of work that I doubt the maintainer will be able to have time for.

Swapping out JOGL for LWJGL as the default for P2D/P3D would be a change that could break a lot of older code, so I'd prefer to make it an optional library for 4.x, but if we're looking for something that will work for a couple years, we might be better off making the switch.

[sampottinger]

Jump forward meaning 11.0.8? Or that we need to continue updating past that once the JEP is available? Or something else I'm missing?

Just that we need to keep updating past. We should be able to stay on the 11 train (I guess there's a very very small chance that it doesn't go into 11?).

Apple Silicon would also be another vote for LWJGL

Agreed

but if we're looking for something that will work for a couple years, we might be better off making the switch.

Yeah I agree with this as well. I would have preferred we kept JOGL but it's looking like it might be difficult with this plus #124

[benfry]

A quick test has things running a little better than expected in translation mode (whatever they call it) on the M1, so I'm feeling a little better about sticking with JOGL as the default to keep things compatible in 4.x. Fingers crossed…

Also locking this thread to so we can keep it focused on implementation instead of general discussion about M1 (as always, the forum is a better place for that). Normally I'd close this since it's too broad (and therefore invites things that get off-topic quickly) but we do need a place to discuss a baseline implementation/testing/plans for M1.

[benfry]

The major obstacles preventing us from doing an Apple Silicon release are primarily the other library/platform components we rely upon. In particular:

• Java VM – The Zulu builds should work fine.

• JOGL – Not clear if/when there will be an Apple Silicon version of JOGL. It also doesn't make sense to ship a version with OpenGL ripped out: Rosetta emulation is working fine (well?) and what would be the point? Bad experience for users, and a support nightmare for me.

• JavaFX – There are Early Access builds of version 17 that include aarch64 (64-bit ARM) for macOS, as well, but we shouldn't ship EA builds in a final product.

• JNA – It looks like support has been added, though there are some indications that it's incomplete. Haven't had a chance to test further.

Those are all the pieces that come to mind at the moment. Once those are set, it will be necessary to do some additional work to add another “architecture” for macOS. But the major hurdles for this work were done when Gottfried and I added Raspberry Pi support. It was/is a similar situation: Linux was primarily 32- or 64-bit Intel, then 32- and 64-bit ARM had to be added as well. (Though we'll only be using 64-bit Intel and 64-bit ARM on macOS.)

[benfry]

Additional resources:

• JEP 391: macOS/AArch64 Port – http://openjdk.java.net/jeps/391
• JVM download options for 64-bit ARM: Azul and Microsoft
• OpenGL is available but deprecated on Apple Silicon

[benfry]

Updates (as of 6 January 2022)

• We're using Adoptium (the new AdoptOpenJDK) builds nowadays, so we'll use that for aarch64 as well (i.e. you can ignore the mention of Zulu builds above)
• Discussion on the JOGL forum about how to build for M1: https://forum.jogamp.org/JOGL-for-Mac-ARM-Silicon-td4040887.html
• From that forum post, detailed instructions from a helpful person on how to do an ARM build: https://github.com/jzy3d/jogl/blob/feature/macosx-arm64/HOW-TO-ADD-ARM64-TO-2.4.md

[benfry]

Updates (15 January 2022)

• Looks like there are non-EA builds of the JavaFX version we're using: https://gluonhq.com/products/javafx/
• JOGL instructions from the last post looking promising
• Still not sure about JNA, but we don't use it a ton on macOS (I… think?) so we may be safe with the current builds.

One question is whether we want to split things out between Intel x64 and Apple Silicon, or if we essentially require fat binaries everywhere. Forcing fat binaries would make everything a lot cleaner—no need to support the separate architectures and whatnot, but I suspect it's just not possible from a practical perspective. Further, we probably need multi-architecture support anyway because Raspberry Pi Linux is still overwhelmingly 32-bit. (So much for my dream of cleaning up all this stuff in 4.0…)

[benfry]

Regarding the fat binary on macOS question raised in the previous comment: there's just no way. We'll just have to do separate Intel and Apple Silicon downloads because there isn't a fat binary JVM even available.

(And since it was sort of a tossup anyway, it doesn't seem like it's desirable anyway… i.e. I'm not looking to figure out how to build a fat binary JDK ourselves anytime soon.)

[benfry]

As of the last couple hours, the infrastructure is now in there to support aarch64, and I manually did an aarch64 build of JOGL from scratch, but a sketch (that draws a single line) crashes immediately on startup on my M1 Mac. Womp womp.

So… that'll require more time.

On a more positive note, the M1 version of the PDE (and sketches, when not using OpenGL) is crazy fast. Just liquid. So good.

[benfry]

Update 24 January 2022… Processing 4.0 beta 4 will include an Apple Silicon version on the download page, however OpenGL crashes immediately on startup.

Remaining items:

• Need a working build of JOGL for aarch64
• appbundler needs Monterey (or Big Sur?) to build for aarch64. But the native build breaks OpenGL when using anything later than Catalina. Needs to be sorted out, and a fat binary created. #284
• Check whether there are any JNA issues (not sure if JNA is even used on the macOS side… may just be Linux or even just Windows).

If someone can get a build of JOGL working, it should just be a matter of replacing the files inside macos-aarch64 inside core/library to test them out.

[benfry]

The JOGL build for M1 (included in beta 4) now confirmed as working with other JOGL demos, but having issues with Processing and/or appbundler. So we'll see if #370 or #284 is what gets fixed first, and how related they are.

Update: seems that the NEWT demos may not be working: #370 (comment)

[benfry]

OpenGL now working as of 4.0 beta 8 (see #370).

This leaves Appbundler and JNA testing as the remaining holdouts for full M1 support.

[benfry]

JNA

• Just bumped JNA to 5.12.1 for 4.0 beta 9.
• The previously mentioned issue has been closed: Test failures on Apple silicon (aarch64) java-native-access/jna#1323
• But there's a new one, though it may be a red herring: com.sun.jna.NativeLibraryTest fails on macOS 12 (Monterey) java-native-access/jna#1423
• In either case, this is resolved enough for now.

appbundler still has some issues (but is working), but those can be found here:

• Figure out why appbundler breaks OpenGL when built on Catalina and later #284
• Create cross-architecture build of appbundler that actually works #364 which cover the problems

So with that, closing this for 4.0 beta 9.