Apple Silicon Support #128
Comments
|
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. |
|
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 |
|
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. |
|
Created by: clankill3r @neilcsmith-net (sorry to go slightly offtopic, but where can I test LWJGL renderer?) |
|
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). |
|
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. |
|
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:
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.) |
|
Created by: benfry Additional resources:
|
|
Created by: benfry Updates (as of 6 January 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…) |
|
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.) |
|
Created by: benfry As of the last couple hours, the infrastructure is now in there to support 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. |
|
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:
If someone can get a build of JOGL working, it should just be a matter of replacing the files inside |
|
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) |
|
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. |
|
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. |
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.
The text was updated successfully, but these errors were encountered: