JOGL for Mac ARM Silicon

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: JOGL for Mac ARM Silicon

Martin
Hi,

Maybe try the rc4 release I shared ?

I sent a link indicating how to get it from maven. If you don’t want it, you can download an rc4 as a zip file. Both provide patched Dylib files for ARM.
If this still does not work, you can find on my jogl GitHub clone a howto to quickly build the native binding .

I encounter the mach-o message you mention when I try loading an ARM dylib in a x86 jvm . Or vice versa . Did you check your PATH or DYLIB_LIBRARY_PATH do not refer to old libs ?

Hope this helps!

Reply | Threaded
Open this post in threaded view
|

Re: JOGL for Mac ARM Silicon

Manu
This post was updated on .
Hello,

Now that the hanging issue can be reproduced, it's much easier to try to find where it occurs in Sweet Home 3D and other JOGL programs.
First, note that this issue happens also when the free version of Rectangle application is running.

After a few tests, I found it happened when a Canvas3D instance is removed from the hierarchy of its container. With this in mind, I let the GC handle container hierarchy cleanup automatically but this delayed only the bug which eventually happened later. It looked like that a patch in Sweet Home 3D wouldn't be enough, but that some changes were required in JOGL itself.

Then after a few refinements in the part of jogamp.opengl.macosx.cgl.MacOSXCGLContext class which handles GL layer detachment and destruction, I found that calling OSXUtil.RunOnMainThread in NSOpenGLImpl#release without waiting its completion (first parameter set to false instead of true) would fix the issue. Eureka!

But when testing under older macOS 10.9 and 10.13, I experienced a similar hanging bug when setting the first parameter of OSXUtil.RunOnMainThread to false even when BetterSnapTool or Rectangle don't run! As the recent changes in the MacOSXCGLContext class were mainly programmed for macOS 10.15 (see the bug #1398), I propose for the moment to keep wait parameter to true only for macOS versions < 10.15 (note that I also tried to simply ignore OSXUtil.RunOnMainThread for old macOS versions, because the call to CGL.setContextView(ctx, 0) that it makes didn't exist before the fix of the bug #1398 but this didn't work).
This won't solve the hanging issue under older macOS versions, but at least, we can ask users to quit BetterSnapTool, Rectangle and the like under these macOS versions (or upgrade their system if they can), until we find a better solution.

Therefore, the current proposed change is to replace the statement:
OSXUtil.RunOnMainThread(true /* wait */, true /* kickNSApp */, new Runnable() {
    @Override
    public void run() {
        CGL.setContextView(ctx, 0);
    } } );
by (for your information, 10.16 version number is returned by Java 8):
boolean wait = System.getProperty("os.version").startsWith("10.") 
    && !System.getProperty("os.version").startsWith("10.15") 
    && !System.getProperty("os.version").startsWith("10.16");
OSXUtil.RunOnMainThread(wait /* wait */, true /* kickNSApp */, new Runnable() {
    @Override
    public void run() {
        CGL.setContextView(ctx, 0);
    } } );
You can test this solution with the modifications made to jogl-all.jar file available in the ZIP file jogl-all-2.4.0-rc-20221117.zip.
I tested it under macOS 10.9, 10.13.6, 12.6.1 Intel, 13.0 ARM and will test it under other macOS versions in the coming days (see further post).

Hope you followed me!
Emmanuel Puybaret
Reply | Threaded
Open this post in threaded view
|

Re: JOGL for Mac ARM Silicon

CharlieBoy
In reply to this post by CharlieBoy
Hi all,

Success!
After installing XCode on my new iMac,  I could use the lipo command.
I used it to extract arm64-only dylibs from the universal dylibs I had gotten from
Sweethome3d and installed these dylibs in place of the universal ones.  
Using the arm64 Zulu JDK 8, everything just worked correctly the first time, no more
loader error messages.
It was immediately clear that it had found the arm64 versions of the libraries,
since the frame rates jumped by 25-50% over the speeds using an Intel JDK 8.
I have since tested this successfully with the arm64 versions of
Eclipse Temurin AdoptOpenJDK 11.0.7 and OpenJDK 11.0.17.

I wonder if there is some hidden flag somewhere that is causing the loading process
to choose to create an x86_64 library instead of an arm64 library from the universal dylib file,
leading to the loader error message in my previous post.

Thanks to manu and martin for their helpful responses.

Charlie
Reply | Threaded
Open this post in threaded view
|

Re: JOGL for Mac ARM Silicon

Martin
In reply to this post by Manu
Thank you a lot for sharing your findings.

I referenced your solution in my JOGL clone issue list here.
Reply | Threaded
Open this post in threaded view
|

Re: JOGL for Mac ARM Silicon

Manu
This post was updated on .
Thank you Martin.

I ran more tests this morning, and I confirm that setting the first parameter of OSXUtil.RunOnMainThread to false worked also in Sweet Home 3D for macOS 10.15, macOS 13 Intel and even for macOS 10.14, which is very good news because it's the last macOS version which supported 32 bit applications that some people may be obliged to keep.
Therefore, this solution works for macOS versions from 10.14 to 13, but the test I proposed to add in NSOpenGLImpl#release must cite 10.14 too.
The proposed change is finally to replace the following statement in jogamp.opengl.macosx.cgl.MacOSXCGLContext class:
OSXUtil.RunOnMainThread(true /* wait */, true /* kickNSApp */, new Runnable() {
    @Override
    public void run() {
        CGL.setContextView(ctx, 0);
    } } );
by:
String osVersion = System.getProperty("os.version");
boolean wait = osVersion.startsWith("10.") 
    && !osVersion.startsWith("10.14") 
    && !osVersion.startsWith("10.15") 
    && !osVersion.startsWith("10.16");
OSXUtil.RunOnMainThread(wait /* wait */, true /* kickNSApp */, new Runnable() {
    @Override
    public void run() {
        CGL.setContextView(ctx, 0);
    } } );
This solution is programmed in the jogl-all.jar file available in the ZIP file jogl-all-2.4.0-rc-20221118.zip and also in SweetHome3D 7.0.2d where you can now import furniture without the hanging issue. I also changed the Implementation-Version value to 2.4.0-rc-20221118 in the MANIFEST.MF file of jogl-all.jar to avoid any confusion.

It would be nice to commit this change in JOGL code, but I don't have the keys for that...
Emmanuel Puybaret
Reply | Threaded
Open this post in threaded view
|

Re: JOGL for Mac ARM Silicon

BelalShareb
In reply to this post by Martin
Hey, I downloaded the latest Jars from the latest build which I assume supports Apple Silicon and x86. I still get this error when trying to run a simple 2d program,

Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /var/folders/2v/3dmc82v53rv9lb3rgkhgpc940000gn/T/jogamp_0000/file_cache/jln4668414692759400130/jln14154233556274098092/natives/macosx-universal/libgluegen_rt.dylib
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2633)
        at java.base/java.lang.Runtime.load0(Runtime.java:768)
        at java.base/java.lang.System.load(System.java:1837)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:604)
        at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:64)
        at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:107)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:488)
        at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:427)
        at com.jogamp.common.os.Platform$1.run(Platform.java:321)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:290)
        at com.jogamp.opengl.GLProfile.<clinit>(GLProfile.java:154)


Thanks in advance.
Reply | Threaded
Open this post in threaded view
|

Re: JOGL for Mac ARM Silicon

Martin
This looks similar to the problem discussed here.

The issue has been solved by changing permissions set by the DEB package manager.

Does this solve your problem?
Reply | Threaded
Open this post in threaded view
|

Re: JOGL for Mac ARM Silicon

BelalShareb
Nope. Error still persists. I executed chmod 755 on /Library/Java/JavaVirtualMachines/zulu-8.jre/Contents/Home/lib/jspawnhelper and /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home/lib/jspawnhelper and changed their permissions as needed.
I didn't change the permissions to other executables however; do I need to do that?
Reply | Threaded
Open this post in threaded view
|

Re: JOGL for Mac ARM Silicon

gouessej
Administrator
In reply to this post by Manu
Thank you for your contribution Emmanuel.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL for Mac ARM Silicon

Martin
In reply to this post by BelalShareb
Then enable debugging information in console by adding the VM argument -Djogamp.debug.IOUtil and then tell us what you get.
Reply | Threaded
Open this post in threaded view
|

Re: JOGL for Mac ARM Silicon

Martin
In reply to this post by Manu
Manu wrote
It would be nice to commit this change in JOGL code, but I don't have the keys for that...
Maybe you can create a pull request here as some other did before. I can't promise to make a full rebuild of JOGL soon, but at least your changes remain available for all (in addition to your explanations).
123