Issue with OpenGL in Geant4 version 11 with MacOS BigSur

tome · November 16, 2022, 8:24pm

Hi,

Running Geant4 version 11.0.3 in my Mac with BigSur, I get an error when trying to open an OpenGL scene (see below).
However with < 11 version (e.g. 10.7.2) there is no problem.

Has someone faced the same issue ?
Many thanks in advance.

Kind regards,
Bernardo Tomé

Idle> /vis/open OGL 600x600-0+0
G4OpenGLXViewer::G4OpenGLXViewer: unable to get a single buffer visual.
G4OpenGLXViewer::G4OpenGLXViewer: unable to get a double buffer visual.
G4OpenGLXViewer::G4OpenGLXViewer: unable to get required visuals.
G4OpenGLStoredX::CreateViewer: error flagged by negative view id in G4OpenGLStoredXViewer creation.
Destroying view and returning null pointer.
ERROR in G4VisManager::CreateViewer: null pointer during OpenGLStoredX viewer creation.
No action taken.

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : UIMAN0123
issued by : G4UImanager::ApplyCommand
WARNING: No viewer created.
Error code : 1
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : UIMAN0123
issued by : G4UImanager::ApplyCommand
Invoked command has failed - see above. Available graphics systems are (short names):
ATree DAWNFILE HepRepFile OGL OGLI OGLIX OGLS OGLSX RayTracer VRML2FILE gMocrenFile
Error code : 1
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

maire · November 16, 2022, 10:22pm

I have exactly the same problem with macOS Monterey (12.6.1)

gybarran · November 17, 2022, 11:32am

You should strongly suspect the X11 window server your are using on your Mac. It is probably XQuartz.
Remember that for “some version” of XQuartz (in particular the 2.7.x), you have to explicitly enable the “OpenGL extensions” with something as “macOS> defaults write org.macosforge.xquartz.X11 enable_iglx -bool true”.

In any case, use the shell command xdpyinfo (from your Mac, or a remote machine) to see if you have the GLX extensions available. (On my Mac it is under /opt/X11/bin).

The upper “defaults” command may be needed to be done again, if upgrading XQuartz. You may have a look to update to latest version (recently I passed to XQuartz/2.8.2 which looks a little bit less… disastrous as the XQuartz/2.7.x. The XQuartz/2.7.11 was the “less worst” of them, but with time passing it appeared to degrade strongly; hard to have a remote session with a Linux, unable to run multiple X11/GLX apps at the same time, unable to run the same app twice without restarting XQuartz, etc…).

What you can do also to check your X11/GLX, is to run another OpenGL app, for example the standard “glxgears” one (from your Mac or a remote Linux). (The glxinfo one could give you also infos).

If you think that your X11/GLX server is ok, then, yes, there is perhaps something now wrong with the logic to choose a “visual” within the G4/vis/G4OpenGLX driver (then relative to the recent macOS upgrades…). But the code within G4OpenGLX to choose a “visual” is quite standard, then I would strongly suspect somethings around your X11-GLX server…

(I can’t test on BigSur and Monterey, I have no machine with these around).

tome · November 17, 2022, 12:48pm

Hi,
Many thanks for the quick reply. glxgears works fine. Also, what made me not suspect of the X11/GLX server is the fact that with Geant4 10.7 the OpenGL visualisation is ok…
Is that a good criteria, or should I still investigate further the “sanity” of the X11/GLX ?
Thanks.

ps - I have XQuartz 2.8.1

gybarran · November 17, 2022, 2:57pm

Ok. Then, yes the X11 server “usual suspect” looks ok for you. It looks to be on the G4OpenGLX side… BUT, just made a “diff” on the G4OpenGLXViewer.cc of geant4-10-07-patch-04, geant4-11-00-patch-03 (and the one on “master”, just in case) where the “get Visual” logic is, and I don’t see any difference here.
(And, again, what is done here with glX is quite standard).

Weird.

gybarran · November 17, 2022, 3:22pm

Just wandering in my notes and looking at the G4OpenGLXViewer.cc code, I see that in the requested attributes for OpenGL, then in the global list variables G4OpenGLXViewer::snglBuf_RGBA and G4OpenGLXViewer::dblBuf_RGBA, there is the “GLX_STENCIL_SIZE, 1,” line which I know posed me problem in my own apps when wanting to display, for example on some Windows X11 server as Xming, with exactly the same symptoms (then “visual not found”). Don’t know, if you master the build of G4, then can you have a try by removing the two lines of code having “GLX_STENCIL_SIZE, 1,” in G4OpenGLXViewer.cc and see what happen? At least to see if you can pass this “get visual” step. (OpenGL stencil looks to be used in G4OpenGLSceneHandler.cc, then you may have problem later…)

tome · November 17, 2022, 9:37pm

Tried as you suggested :
$ grep GLX_STENCIL /usr/local/Geant4/source/11.00.03/source/visualization/OpenGL/src/G4OpenGLXViewer.cc
//CBT GLX_STENCIL_SIZE, 1,
//CBT GLX_STENCIL_SIZE, 1,

and recompiled :

$ geant4-config --prefix

/usr/local/Geant4/install/11.0.3/bin/…

$ ls -ltr geant4-config --prefix/lib/libG4O*
-rwxr-xr-x 1 bernardo wheel 263320 Nov 17 21:24 /usr/local/Geant4/install/11.0.3/bin/…/lib/libG4OpenGL.dylib

But get the same error:

/vis/open OGLIX 600x600-0+0
G4OpenGLXViewer::G4OpenGLXViewer: unable to get a single buffer visual.
G4OpenGLXViewer::G4OpenGLXViewer: unable to get a double buffer visual.
G4OpenGLXViewer::G4OpenGLXViewer: unable to get required visuals.
G4OpenGLImmediateX::CreateViewer: error flagged by negative view id in G4OpenGLImmediateXViewer creation.
Destroying view and returning null pointer.
ERROR in G4VisManager::CreateViewer: null pointer during OpenGLImmediateX viewer creation.
No action taken.

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : UIMAN0123
issued by : G4UImanager::ApplyCommand
WARNING: No viewer created.
Error code : 1
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : UIMAN0123
issued by : G4UImanager::ApplyCommand
Invoked command has failed - see above. Available graphics systems are (short names):
ATree DAWNFILE HepRepFile OGL OGLI OGLIX OGLS OGLSX RayTracer VRML2FILE gMocrenFile
Error code : 1
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

***** Illegal parameter (1) </vis/open OGLIX 600x600-0+0> *****

***** Batch is interrupted!! *****

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : UIMAN0123
issued by : G4UImanager::ApplyCommand
Command aborted (1)
Error code : 1

gybarran · November 18, 2022, 3:23pm

Ok, then no miracle happened.

Assuming that the problem comes from the “environment” (and not a pure internal G4 one), well, on macOS, there is the problem that we have two OpenGL around, the one of Apple, and the one (Mesa) coming with a X11 installation. Don’t know, can you check on the final binary with “otool -L ”, that you have only X11 related libs for windowing and graphics, in particular only the libGL one coming with your X11 installation, and not the Apple “OpenGL.framework”. On my machine I installed X11 with Macports, and if I do “otool -L” on a simple X11/GL app, I have:

/opt/local/lib/libGL.1.dylib (compatibility version 4.0.0, current version 4.0.0)
/opt/local/lib/libX11.6.dylib (compatibility version 11.0.0, current version 11.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

and then NOT having in the list:

/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)

The idea is that if you are not “X11 consistent”, then “things may happen”. (I am not an expert of the G4/cmake system, but there is a lot of changes here between 10.7 and 11.0…, then a difference in the build, and then how to pick up X11 and OpenGL may be considered).

Ah, yes, another important point: take care of NOT using the X11 and libGL under /opt/X11, I had a lot of problems with them… and in particular if mixing what is here with what is under /opt/local/lib coming from Macports.
(If you do a “nm /opt/X11/lib/libGL.a” you will see that this is some kind of bridge to the Apple GL, which is not the case if doing a “nm /opt/local/lib/libGL.a” which looks to be a “true Mesa”). (And the same if using some Brew X11&GL; be sure to take both from the same distribution).

Another idea would be to build a G4-11.0/X11/GL on a Linux and see what happen when displaying on your macOS/XQuartz… (because on the Linux, we would be sure to be X11 consistent, and then keep the Mesa OpenGL).

tome · November 21, 2022, 5:00pm

Ok, I ´ll try as you suggest. In the meantime I asked around some students and those using macOS with Geant4 11.0 are not finding any problem : Monterey 12.6. and Ventura 13.0.1.

So it seems the problem is on my side…
Many thanks.

tome · November 21, 2022, 5:46pm

Doing
otool -L Brachy | grep libGL

I get
/opt/X11/lib/libGL.1.dylib (compatibility version 4.0.0, current version 4.0.0)

Is there a way of forcing the use of the OGL under /opt/local/lib/ ?

If I do in my build directory :
make edit_cache

the only X11 related configs are:

tome · November 22, 2022, 12:04pm

I just tried building G4-11 on a Linux and displaying on my macOS and it’s fine !
Thanks.

allison · November 22, 2022, 12:46pm

That’s a possible solution. Great. Thanks for letting us know.

tome · November 22, 2022, 12:56pm

Well, this was in the process of trying to find out why in my macOS I can’t display a OpenGL scene with G4 11. Not that I solved it…

gybarran · November 22, 2022, 12:59pm

Ok, then the problem is not in your XQuartz server but probably in the way you pick the X11 and X11-GL libs on your Mac at build and run time.

Then on your Mac, if you suspect that “/opt/X11” is the culprit (I think it could be) and if your are the admin, an “awful hacker brutal savage” way, if you have X11 installed elsewhere than /opt/X11, (for exa under /opt/local for Macports) is to temporarily rename /opt/X11/include and /opt/X11/lib to something else, rebuild, and then hope that cmake picks up the “elsewhere installation”.

For a more civilised way, if I look at the content of cmake/Modules/FindXQuartzGL.cmake, I see that for the variables XQuartzGL_INCLUDE_DIR, XQuartzGL_gl_LIBRARY, etc : /opt/X11 comes before /usr/local (then a Homebrew install) that itself comes before /opt/local (then Macports). These variables can probably be changed from some -D at the level of the cmake command or some custom cmake file, but I never practiced this. (Then another “awful hacker brutal savage” way would be to customise this file to remove the /opt/X11 paths and then rebuild…). I am not an expert of cmake, then others may help here in order to do that properly…

And, again, being “consistent” is important here; then be sure to take all X11 libs (including libGL) from the same source. (You can use “otool -L” on all of them to see the dependencies).

tome · November 23, 2022, 10:30am

Thanks ! I’ll try first and blindly the “awful hacker brutal savage” way, to see if it solves the problem. Then I’ll think how to do it in civilised way…
Indeed I was thinking if cmake could be configured to search for GL stuff elsewhere.
But didn’t find anything in the Installation Guide…