Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenGL sketches crash on the aarch64 (Apple Silicon) version #370

Closed
processing-bot opened this issue Jan 24, 2022 · 21 comments
Closed

OpenGL sketches crash on the aarch64 (Apple Silicon) version #370

processing-bot opened this issue Jan 24, 2022 · 21 comments

Comments

@processing-bot
Copy link
Collaborator

Created by: 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 #284 which itself may be a known upstream bug: TheInfiniteKind/appbundler#70

@processing-bot
Copy link
Collaborator Author

Created by: jaegonlee

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

Code terminated in next step
joglerror
.

@processing-bot
Copy link
Collaborator Author

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

@processing-bot
Copy link
Collaborator Author

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

@processing-bot
Copy link
Collaborator Author

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

@processing-bot
Copy link
Collaborator Author

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

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.

@processing-bot
Copy link
Collaborator Author

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

@processing-bot
Copy link
Collaborator Author

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

@processing-bot
Copy link
Collaborator Author

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

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

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

@processing-bot
Copy link
Collaborator Author

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

code3

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Sounds like good progress! Though fragile :)

@processing-bot
Copy link
Collaborator Author

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

@processing-bot
Copy link
Collaborator Author

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

@processing-bot
Copy link
Collaborator Author

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

@processing-bot
Copy link
Collaborator Author

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

@processing-bot
Copy link
Collaborator Author

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

keymap

key mapping is ok now.

@processing-bot
Copy link
Collaborator Author

Created by: 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];
}

ctxupdate

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

processing4

@processing-bot
Copy link
Collaborator Author

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

@processing-bot
Copy link
Collaborator Author

Created by: codeanticode

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

@processing-bot
Copy link
Collaborator Author

Created by: benfry

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

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

@processing-bot
Copy link
Collaborator Author

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

@processing-bot
Copy link
Collaborator Author

Created by: github-actions[bot]

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant