Mesa 17.2.0 renderer driver name change error, causes GLProfile not mapped initialization error

Hello all,
I've got some issues regarding jogl context initialization while using new Mesa 17.2.0 on my arch linux machine. To make some short summary, while using slightly older Mesa (17.1.5), GL renderer was named:
Gallium 0.4 on AMD HAWAII (DRM 3.15.0 / 4.12.12-1-ARCH, LLVM 4.0.1)
and all was working well, while the new renderer is named:
AMD Radeon R9 200 Series (AMD HAWAII / DRM 3.15.0 / 4.12.12-1-ARCH, LLVM 4.0.1)
GLContext would therefore not recognize by this new name that it is actually Mesa renderer/driver - context and profile initialization fails and things does not work at all.

Its quite easy, anyway here are some informations regarding my machine and jogl:
OS/Distro: Linux/Archlinux (up to date)
Graphics card: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT / Grenada XT [Radeon R9 290X/390X]
Video drivers: xf86-video-amdgpu-1.4.0-1-x86_64 (radeon module is blacklisted because of OpenCL incompatibility, so amdgpu module is used in all setups.)
jogl version and package is from: http://jogamp.org/deployment/v2.3.2/archive/jogamp-fat-all.7z
All other important informations could be found in all of the following debug outputs....

debug output of GLProfile.get(GLProfile.GL2) on Mesa 17.1.5 - mesa driver recognized:
https://pastebin.com/PQ1jrmtZ

debug output of GLProfile.get(GLProfile.GL2) on Mesa 17.2.0 - mesa driver NOT recognized:
https://pastebin.com/3SAuNfv7

debug output of GLProfile.get(GLProfile.GL2) on Mesa 17.2.0 with modified GLContextImpl - mesa driver recognized:
https://pastebin.com/cJJ6cp1x

I was able to recognize the problem just by diffing first two debug outputs (lines 212-216 quirks...) where renderer names are shown (or missing in the buggy case). After putting some breakpoints to quirks init, the issue immediately shown itself.

To sum it up, actual problem lies in function setRendererQuirks in class GLContextImpl.java on line 2116 (alternatively https://github.com/sgothel/jogl/blob/master/src/jogl/classes/jogamp/opengl/GLContextImpl.java#L2136) where:
final boolean isDriverMesa = glRenderer.contains(MesaSP) || glRenderer.contains("Gallium ");
needs to be changed to:
final boolean isDriverMesa = glRenderer.contains(MesaSP) || glRenderer.contains("Gallium ") || glRenderer.startsWith("AMD ");
this causes the context to be correctly initialized and things work well again. It even looks like there was already some intention to implement this Mesa AMD renderer - as seen commented 8 lines above the culprit, where:
// final String MesaRendererAMDsp = " AMD ";
I do not know whether this is the best solution as I do not see too deep to JOGL internals, so I am just documenting my findings for you this way. Hope this helps.

Have a nice day.
Zeno

Hi

The suggested fix would cause a regression as a renderer can contain AMD and can have nothing to do with Mesa.

You should fill a bug report. I'll try to reproduce this bug on my own machine under Mageia Linux 6.

Hi,
glVersion string could be of some help then, (loaded at GLContextImpl.java:1634 -> glGetStringInt(GL.GL_VERSION, glGetStringPtr)), returns following:
OpenGL ES 3.1 Mesa 17.2.0
Well, to be honest, it is quite a mess, according to: https://www.khronos.org/opengl/wiki/OpenGL_Context#OpenGL_version_number 
this could change to anything anytime as it depends on specific GL implementations.
Have a nice day.
Zeno

I'm currently using Mesa 17.1.4. I'll fill a bug report soon. Thank you for the hints.

The option A seems to be infeasible to me. I can't fix Mesa itself and there are still buggy versions installed on numerous computers.

In my humble opinion, it will force us to release a maintenance version because the impact is quite big. We can't stay with such an important unfixed bug affecting GNU Linux.

I can replicate the error. I was wondering whether the maintenance version was released, and where I might be able to find it.

Also on Arch Linux x64, running JOGL v2.3.2.

Code is extending GLCanvas, and upon trying to add an event listener it crashes with the following stacktrace:

Exception in thread "AWT-EventQueue-0" java.lang.InternalError: XXX0 profile[1]: GL3bc -> profileImpl GL4bc !!! not mapped
        at com.jogamp.opengl.GLProfile.computeProfileMap(GLProfile.java:2071)
        at com.jogamp.opengl.GLProfile.initProfilesForDeviceCritical(GLProfile.java:1954)
        at com.jogamp.opengl.GLProfile.initProfilesForDevice(GLProfile.java:1875)
        at com.jogamp.opengl.GLProfile.initProfilesForDefaultDevices(GLProfile.java:1842)
        at com.jogamp.opengl.GLProfile.access$000(GLProfile.java:80)
        at com.jogamp.opengl.GLProfile$1.run(GLProfile.java:230)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.opengl.GLProfile.initSingleton(GLProfile.java:216)
        at com.jogamp.opengl.GLProfile.getDefaultDevice(GLProfile.java:2027)
        at com.jogamp.opengl.awt.GLCanvas.<init>(GLCanvas.java:264)
        at com.jogamp.opengl.awt.GLCanvas.<init>(GLCanvas.java:231)
        at com.jogamp.opengl.awt.GLCanvas.<init>(GLCanvas.java:218)
        at JOGL2Setup_GLCanvas.<init>(JOGL2Setup_GLCanvas.java:27)
        at JOGL2Setup_RendererMain.<init>(JOGL2Setup_RendererMain.java:26)
        at JOGL2Setup_RendererMain$2.run(JOGL2Setup_RendererMain.java:62)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
        at java.awt.EventQueue.access$500(EventQueue.java:97)
        at java.awt.EventQueue$3.run(EventQueue.java:709)
        at java.awt.EventQueue$3.run(EventQueue.java:703)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Process finished with exit code 0

Line 27 in JOGL2Setup_GLCanvas is:
public JOGL2Setup_GLCanvas() {
        this.addGLEventListener(
   }


OpenGL renderer string: AMD HAWAII (DRM 2.50.0 / 4.13.5-1-ARCH, LLVM 5.0.0)

We have found a fix, it will be put into the next maintenance release:
https://jogamp.org/bugzilla/show_bug.cgi?id=1357

Thanks for the link to the bug report.

I'll recompile it on my system in the meantime using the suggested fix.

I rebuilt jogl on Fedora with the proposed fix, it did fix the problem in SciLab, but the same or very similar problem still exists with a proprietary CAD program called ProtocaseDesigner. The software can be downloaded at no cost here:
https://www.protocasedesigner.com/download/

I attempted to add this information to the bugzilla entry, but I cannot find a link to register on bugzilla, so have to enter the information in the forum.

When starting the startup process never completes, these messages are logged:

==== exception ====java.lang.InternalErrorXXX0 profile[1]: GL3bc -> profileImpl GL4bc !!! not mapped --- stack trace ----java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=com.protocase.viewer.JDesigner$$Lambda$5/758705033@1853cdc1,notifier=null,catchExceptions=false,when=1518148914822] on sun.awt.X11.XToolkit@5679616fjava.lang.InternalError: XXX0 profile[1]: GL3bc -> profileImpl GL4bc !!! not mapped
        at com.jogamp.opengl.GLProfile.computeProfileMap(GLProfile.java:2071)
        at com.jogamp.opengl.GLProfile.initProfilesForDeviceCritical(GLProfile.java:1954)
        at com.jogamp.opengl.GLProfile.initProfilesForDevice(GLProfile.java:1875)
        at com.jogamp.opengl.GLProfile.initProfilesForDefaultDevices(GLProfile.java:1842)
        at com.jogamp.opengl.GLProfile.access$000(GLProfile.java:80)
        at com.jogamp.opengl.GLProfile$1.run(GLProfile.java:230)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.opengl.GLProfile.initSingleton(GLProfile.java:216)
        at com.jogamp.opengl.GLProfile.getProfileMap(GLProfile.java:2297)
        at com.jogamp.opengl.GLProfile.get(GLProfile.java:988)
        at com.jogamp.opengl.GLProfile.getDefault(GLProfile.java:722)
        at com.jogamp.opengl.GLProfile.getDefault(GLProfile.java:733)
        at com.protocase.viewer.rendering.gl.GLInstance.getDefaultGLCapabilities(GLInstance.java:375)
        at com.protocase.viewer.rendering.gl.GLInstance.<init>(GLInstance.java:79)
        at com.protocase.viewer.rendering.gl.GLCanvasInstance.<init>(GLCanvasInstance.java:17)
        at com.protocase.viewer3D.modular.Editor3DGLCanvas.initCanvas(Editor3DGLCanvas.java:25)
        at com.protocase.viewer3D.modular.Editor3DCanvas.<init>(Editor3DCanvas.java:53)
        at com.protocase.viewer3D.modular.Editor3DGLCanvas.<init>(Editor3DGLCanvas.java:20)
        at com.protocase.viewer3D.modular.editor.builders.DesignerEditor3DBuilder.buildCanvas(DesignerEditor3DBuilder.java:87)
        at com.protocase.viewer3D.modular.editor.builders.Editor3DDirector.makeEditor3D(Editor3DDirector.java:35)
        at com.protocase.viewer3D.modular.Editor3DFactory.createEditor3D(Editor3DFactory.java:21)
        at com.protocase.viewer.JDesigner.<init>(JDesigner.java:127)
        at com.protocase.viewer.JDesigner.lambda$main$11(JDesigner.java:1310)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
        at java.awt.EventQueue.access$500(EventQueue.java:97)
        at java.awt.EventQueue$3.run(EventQueue.java:709)
        at java.awt.EventQueue$3.run(EventQueue.java:703)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
        at com.protocase.viewer.EventQueueProxy.dispatchEvent(EventQueueProxy.java:39)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

The "profileImpl GL4bc !!! not mapped" message makes me think this is the same problem, but this is after recompiling with the "|| glVersion.contains(MesaSP)" added to the isDriverMesa check.
Running on an  AMD RX 460 card on 4.14 kernel with amdgpu driver and mesa 17.2.4  (Fedora 27 with latest updates).

Hey

There is no such link. Send me an email and I'll create an account for you. We were spammed, we had to close the registration.

Please can you run glxinfo on this machine?

On Fri, February 9, 2018 5:05 pm, gouessej [via jogamp] wrote:
> Please can you run glxinfo on this machine?

I add the information to this forum topic:
http://forum.jogamp.org/Mesa-17-2-0-renderer-driver-name-change-error-causes-GLProfile-not-mapped-initialization-error-tp4038176p4038613.html

This is what I saved from glxinfo previously, I will have to get the full
output later if you like:

$ glxinfo64 | grep -i opengl
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon (TM) RX 460 Graphics (AMD POLARIS11 /
DRM 3.19.0 / 4.14.12-300.rt10.1.fc27.ccrma.x86_64+
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.4
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.2.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.2.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:



best regards,
Chris Caudle

Here is the full glxinfo64 output from my machine.glxinfo_amd_rx460_mesa_17.txt

Someone also mentioned an earlier post having trouble getting Sweet Home 3D architecture software to run.  I tried that package and got a similar error:
Caused by: java.lang.InternalError: XXX0 profile[1]: GL3bc -> profileImpl GL4bc !!! not mapped

but SciLab does start now, where previously (before patching jogl) it would stop.  So the patch seems to improve at least some behavior.

Thank you for the output. My fix should work as "OpenGL version string" contains "Mesa ":
OpenGL version string: 3.0 Mesa 17.2.4

gouessej wrote

My fix should work as "OpenGL version string" contains "Mesa ":

Yes, so is there a way to make sure the fix is working as intended, and to have jogl dump out which code path it took to determine the profile to use?

Where does that error message of profile not mapped come from?
$ grep "profileImpl GL4bc" *.java
$ pwd
~/rpmbuild/BUILD/jogl-v2.3.2/src/jogl/classes/jogamp/opengl

I went up to the src directory and grepped for "profileImpl GL4bc" in all the .java files and all the .c files but did not find it.  Is there a file of message strings separate from the code that I did not see?

This is the file which was compiled, the patch is correct, yes?

    final boolean isWindows = Platform.getOSType() == Platform.OSType.WINDOWS;
    final boolean isDriverMesa = glRenderer.contains(MesaSP) || glRenderer.contains("Gallium ") || glVersion.contains(MesaSP);
    final boolean isDriverATICatalyst;
    final boolean isDriverNVIDIAGeForce;

After looking through the file quickly it seems error strings are built up by concatenating shorter strings along with variables or defined strings, so probably why a simple grep cannot find that error message.

What are next debug steps to determine why the "GL3bc -> profileImpl GL4bc !!! not mapped" error is still occuring?

The logs should indicate with renderer quirks are effectively loaded. If the error is still occurring, it means that either the program is not using the patched version or there is another bug.

Please provide the detailed bug log:
http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing

What is the expected environment for those script files?  When trying to run test.sh it complains that the main class cannot be found:
/usr/bin/java
openjdk version "1.8.0_161"
OpenJDK Runtime Environment (build 1.8.0_161-b14)
OpenJDK 64-Bit Server VM (build 25.161-b14, mixed mode)
LIBXCB_ALLOW_SLOPPY_LOCK:
LIBGL_DRIVERS_PATH:
LIBGL_DEBUG:
java
Error: Could not find or load main class com.jogamp.newt.opengl.GLWindow

I changed directories to the jogl-v2.3.2/build directory and it got farther but still had an error:

/usr/bin/java
openjdk version "1.8.0_161"
OpenJDK Runtime Environment (build 1.8.0_161-b14)
OpenJDK 64-Bit Server VM (build 25.161-b14, mixed mode)
LIBXCB_ALLOW_SLOPPY_LOCK:
LIBGL_DRIVERS_PATH:
LIBGL_DEBUG:
java
CLASSPATH: jar/gluegen-rt.jar:jar/jogl-all.jar

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.NoClassDefFoundError: com/jogamp/common/type/WriteCloneable
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
        at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
        at java.lang.Class.getMethod0(Class.java:3018)
        at java.lang.Class.getMethod(Class.java:1784)
        at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
Caused by: java.lang.ClassNotFoundException: com.jogamp.common.type.WriteCloneable
        at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 19 more

Seems it cannot find jogamp classes.

in test.sh the CLASSPATH env is set to:
CLASSPATH=jar/gluegen-rt.jar:jar/jogl-all.jar

jogl-all.jar exists, but not gluegen-rt.jar:
$ ls jar
atomic
jogl-all-android-natives-linux-amd64.jar
jogl-all.jar
jogl-all-mobile.jar
jogl-all-mobile-natives-linux-amd64.jar
jogl-all-natives-linux-amd64.jar
jogl-all-noawt.jar
jogl-all-noawt-natives-linux-amd64.jar

In the fedora package the gluegen files are all in a different directory, it that causing the test script to break in some way? test_dbg.sh fails in the same way, so I have to get past this problem before I can send the requested debug information.

Ugh!  I'm banging my head against my desk, I just realized that the CAD application I was still having problems with shipped its own copy of jogl-all.jar, so the entire time after I installed the patched version of jogl the application was still using an old copy.  That is why the fedora installed scilab worked, because it uses system libraries.  After copying the newly patched jar file into the CAD program's lib directory that program began working as well.  I will let the application developer know that they should pull in a new version of jogl for their next update.
Thank you for looking at this problem, I'm sorry I did not notice the app shipped its own version of the library sooner, it would have saved all of us time wasted.  
In short, patch seems good, verified working after correcting for user error of using old library after patching.