Apple Silicon Support

[processing-bot]

Created by: 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.

[processing-bot]

Created by: 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.

[processing-bot]

Created by: 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

[processing-bot]

Created by: neilcsmith-net

We already have a working version of the LWJGL renderer that is running on all 3 OS, but it requires a couple of new methods in PApplet (no way around that, particularly on macOS!). We're also planning on still supporting JOGL at some point, but need to do this also by abstraction of the JOGL code into a separate package (for us JPMS module). This would allow shipping either renderer rather than both for platforms / exported sketches.

I'm still happy to help with backporting and fixing this upstream if at all possible.

I'm not sure if LWJGL does have a Metal backend?! They do have Vulkan, which has a Metal compatibility layer as far as I know. But I have a feeling OpenGL(ES) on Metal is a more usable future option?

The next Java LTS (17) is out in a year. I'd be surprised if the support didn't get backported to 11 by various vendors though.

[processing-bot]

Created by: clankill3r

@neilcsmith-net (sorry to go slightly offtopic, but where can I test LWJGL renderer?)

[processing-bot]

Created by: neilcsmith-net

@clankill3r outside of PraxisLIVE, where it's the version we ship with but currently without ARM binaries, the source is at https://github.com/praxis-live/libp5x and the maven binaries are at https://search.maven.org/search?q=g:org.praxislive.libp5x Email me directly if you want any more info (email on GitHub profile).

[processing-bot]

Created by: 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.

[processing-bot]

Created by: 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.)

[processing-bot]

Created by: 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

[processing-bot]

Created by: 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

[processing-bot]

Created by: 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…)

[processing-bot]

Created by: 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.)

[processing-bot]

Created by: 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.

[processing-bot]

Created by: 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.

[processing-bot]

Created by: 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)

[processing-bot]

Created by: 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.