OpenGL sketches crash on the aarch64 (Apple Silicon) version

[benfry]

From the release notes for 4.0 beta 4:

Against my better judgement, I'm posting a release that's native for Apple Silicon. OpenGL is currently broken. Sketches crash immediately. You should only use it if you're a masochist. Or a masochist that likes extremely fast but very incomplete software, and won't file bug reports saying “OpenGL is broken.” But it's being posted for folks who do not need OpenGL, and/or want to help debug.

This may simply be due to processing/processing4#284 which itself may be a known upstream bug: TheInfiniteKind/appbundler#70

[jaegonlee]

I tested some jogl examples, they works ok except using newt. It crashes when creating GLWindow.

Code terminated in next step

.

[benfry]

Thanks for looking into it, good to know… That could be a problem in the JOGL build that I made not properly supporting NEWT. Which could be good news in some ways (maybe I did something dumb), or bad news in others (NEWT may need more complicated changes for aarch64).

[benfry]

Confirming the crash inside NEWT for us (this is jdb output of running an exported application).

Step completed: "thread=main", jogamp.newt.WindowImpl.<clinit>(), line=204 bci=57

main[1] step
> 
Step completed: "thread=main", jogamp.newt.driver.macosx.WindowDriver.<clinit>(), line=67 bci=0

main[1] step
> 
Step completed: "thread=main", jogamp.newt.driver.macosx.DisplayDriver.initSingleton(), line=102 bci=0

main[1] step
> 
Step completed: "thread=main", jogamp.newt.driver.macosx.WindowDriver.<clinit>(), line=68 bci=3

main[1] step
> 
The application has been disconnected

That's inside PSurfaceJOGL.initDisplay(), though it only got that far after disabling the earlier NewtFactory.setWindowIcons(res) call, which I was hoping was just happening at the wrong time.

[benfry]

Though perhaps interestingly, setWindowIcons() only does an assignment:

  public static void setWindowIcons(ClassResources var0) {
    defaultWindowIcons = var0;
  }

…so it seems there's something in the static initialization of the NEWT code that's causing trouble. Which also means it could be pretty early in loading the native library.

[benfry]

The aarch64 JOGL builds were done with these instructions: https://github.com/jzy3d/jogl/blob/feature/macosx-arm64/HOW-TO-ADD-ARM64-TO-2.4.md

And the result of that is also in a Maven repository:

• http://maven.jzy3d.org/releases/org/jogamp/jogl/jogl-all-natives-macosx-universal/v2.4.0-rc4/jogl-all-natives-macosx-universal-v2.4.0-rc4.jar
• http://maven.jzy3d.org/releases/org/jogamp/gluegen/gluegen-rt-natives-macosx-universal/v2.4.0-rc4/gluegen-rt-natives-macosx-universal-v2.4.0-rc4.jar

However, swapping these in still leaves a crash in the same place when initializing a Processing sketch. I'd have to check whether it's the same for NEWT demos.

[benfry]

Ok, and confirming that the NEWT demos crash the same way, using my build and the jzy3d builds.

Start the debugger:

jdb -classpath \
  gluegen-rt.jar:gluegen-test-util.jar:jogl-all.jar:jogl-test.jar:junit.jar \
  com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT

Commands given to the debugger:

stop in jogamp.newt.driver.macosx.DisplayDriver.initSingleton
step
step

And finally:

Step completed: "thread=main", jogamp.newt.driver.macosx.WindowDriver.<clinit>(), line=68 bci=3

…as the last line before the crash.

Or for the full trace:

Initializing jdb ...
> stop in jogamp.newt.driver.macosx.DisplayDriver.initSingleton
Deferring breakpoint jogamp.newt.driver.macosx.DisplayDriver.initSingleton.
It will be set after the class is loaded.
> run
run com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
> 
VM Started: position null
size 640 x 480
resize null
screen 0
translucent false
forceAlpha -1
undecorated false
atop false
abottom false
resizable true
sticky false
max_vert false
max_horz false
fullscreen false
mouseVisible true
mouseConfined false
pointerIcon false
loops 1
loop shutdown false
forceES2 false
forceES3 false
forceGL3 false
forceGL2 false
forceDebug false
forceTrace false
swapInterval 1
exclusiveContext false
useAnimator true
sysExitWithin none
mappedBuffers false
demoType 1
traceMouse false
JUnit version 4.8.2
++++ Test Singleton.ctor()
++++ Test Singleton.lock()
SLOCK [T SingletonServerSocket1-localhost/127.0.0.1:59999 @ 1643513410004 ms III - Start
SLOCK [T main @ 1643513410005 ms +++ localhost/127.0.0.1:59999 - Locked within 9 ms, 1 attempts
.++++ TestCase.setUp: com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT - test03_GL3
requested: vsync 1, GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono  , hw, GLProfile[GL3/GL4.hw], on-scr[.]]
Set deferred breakpoint jogamp.newt.driver.macosx.DisplayDriver.initSingleton

Breakpoint hit: "thread=main", jogamp.newt.driver.macosx.DisplayDriver.initSingleton(), line=102 bci=0

main[1] step
> 
Step completed: "thread=main", jogamp.newt.driver.macosx.WindowDriver.<clinit>(), line=68 bci=3

main[1] step
> 
The application has been disconnected

also CCing @codeanticode for the progress update…

[benfry]

Oh, and when run with appbundler, we get the full macOS crash thing, with this possible clue in the details:

Application Specific Information:
-[NSOpenGLContext update] must be called from the main thread if the context has a view.

[jaegonlee]

Adding 2 lines of codes, it works with Jogl Newt Example.
(I don't know why)

MacNewtNSWindow.m(jogl/src/newt/native)
return NULL;

MacWindow.m(jogl/src/newt/native)
sleep(1);

OpenGL sketchs are running, but can't draw anything.

[jaegonlee]

OpenGL sketches works fine after short delay.

void setup() {
  size(400, 400, P2D);
}

void draw() {
  if (frameCount > 1) {
    // draw something
    background(0);
    ellipse(200, 200, 100, 100);
  }
}

[benfry]

Sounds like good progress! Though fragile :)

[benfry]

Hm, also seeing similar framebuffer errors when running the Intel version on an M1 Max:

OpenGL error 1286 at top beginDraw(): invalid framebuffer operation
OpenGL error 1286 at bot beginDraw(): invalid framebuffer operation

[benfry]

@jaegonlee Does the sleep() hack work consistently for you? I'm starting to wonder whether we want to just go with the hack for now (so that it's not just crashing for folks) until someone has the time or wherewithal to fix it properly.

[jaegonlee]

@benfry some errors occur (as you mentioned above) when launching, but codes are running without problems.
(except resizing window)

OpenGL error 1286 at top beginDraw(): invalid framebuffer operation
OpenGL error 1286 at bot beginDraw(): invalid framebuffer operation
OpenGL error 1286 at bot endDraw(): invalid framebuffer operation

[benfry]

And I'm guessing keys are disabled as well (or at least keys that aren't just a-z and 0-9) because it's skipping the function to set up the mappings?

[jaegonlee]

Calling TISGetInputSourceProperty() to get keyboard layout cause the crash.
Instead of adding return NULL; to pass it, addiing dispatch_async could avoid the crash when mapping the keys.

MacNewtNSWindow.m(jogl/src/newt/native)

dispatch_async(dispatch_get_main_queue(), ^(){ 
    CKCH_CreateDictionaries(); 
});

key mapping is ok now.

[jaegonlee]

I could fix the problem with newt window.
-[NSOpenGLContext update] must be called from the main thread if the context has a view. golang/go#35177 (comment)

MacOSXWindowSystemInterface.m(jogl/src/jogl/native/macosx/)

void updateContext(NSOpenGLContext* ctx) {
  NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
  NSView *nsView = [ctx view];
  if(NULL != nsView) {
      DBG_PRINT("updateContext.0: ctx %p, ctx.view %p\n", ctx, nsView);
      // [ctx update]; from 
      [ctx performSelectorOnMainThread:@selector(update) withObject:nil waitUntilDone:NO]; // to 

      DBG_PRINT("updateContext.X\n");
  }
  [pool release];
}

no need to sleep(1) or delay, and there're no more framebuffer errors.

[benfry]

Fantastic! This is exactly what we're looking for. I'll take a look at patching that up and if it works, maybe we'll push out a new beta. This would be huge!

[codeanticode]

Nice, I have been following this issue looks you have made great progress. Thanks a lot @jaegonlee !!

[benfry]

Ok, with the help of @jaegonlee's patches:

• https://github.com/jzy3d/jogl/pull/17/files and
• https://github.com/jzy3d/jogl/pull/16/files)

…I was able to hack together a working JOGL for ARM for 4.0 beta 8. 🎉

[benfry]

To build from an (already existing) git clone, you'll need to clear out the old JOGL libraries:

cd /path/to/processing4/core
ant clean-jogl

then do a fresh build:

cd ../build
ant run

[github-actions]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.