Repository navigation
Apple Silicon Support #128
Description
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.
Activity
processing-bot commentedon Sep 1, 2020
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 commentedon Sep 1, 2020
Created by: sampottinger
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?).
Agreed
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 commentedon Sep 2, 2020
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 commentedon Nov 30, 2020
Created by: clankill3r
@neilcsmith-net (sorry to go slightly offtopic, but where can I test LWJGL renderer?)
processing-bot commentedon Nov 30, 2020
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 commentedon Dec 15, 2020
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 commentedon Jun 20, 2021
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 commentedon Jun 20, 2021
Created by: benfry
Additional resources:
processing-bot commentedon Jan 6, 2022
Created by: benfry
Updates (as of 6 January 2022)
aarch64as well (i.e. you can ignore the mention of Zulu builds above)processing-bot commentedon Jan 15, 2022
Created by: benfry
Updates (15 January 2022)
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 commentedon Jan 18, 2022
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 commentedon Jan 23, 2022
Created by: benfry
As of the last couple hours, the infrastructure is now in there to support
aarch64, and I manually did anaarch64build 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 commentedon Jan 24, 2022
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:
aarch64appbundlerneeds Monterey (or Big Sur?) to build foraarch64. But the native build breaks OpenGL when using anything later than Catalina. Needs to be sorted out, and a fat binary created. #284If someone can get a build of JOGL working, it should just be a matter of replacing the files inside
macos-aarch64insidecore/libraryto test them out.processing-bot commentedon Jan 30, 2022
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 commentedon Apr 23, 2022
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.
processing-bot commentedon Aug 2, 2022
Created by: benfry
JNA
appbundler still has some issues (but is working), but those can be found here:
So with that, closing this for 4.0 beta 9.