Need Help Solving OpenGL/GLSL 4.4 Issues

jmaasing wrote

Vacation today so I had some time to test your code :-)

Thanks. I appreciate it :)

jmaasing wrote

I haven't fixed it yet but there are two problems I saw right away, if you add

    public void init(GLAutoDrawable drawable) {
                drawable.setGL(new DebugGL4((GL4) drawable.getGL()));
        GL4 gl = (GL4) drawable.getGL();

You will see that OpenGL complains about invalid operation (at least on my platform):
Exception in thread "main-AWTAnimator" java.lang.RuntimeException: javax.media.opengl.GLException: Thread[AWT-EventQueue-0,6,main] glGetError() returned the following error codes after a call to glGenVertexArrays(<int> 0x1, <[I>, <int> 0x0): GL_INVALID_OPERATION ( 1282 0x502),

I refactored my pixel-drawing demo. Some of the changes (will post in full at bottom) in init(...)

    GL4 gl = (GL4) drawable.getGL();
    drawable.setGL(new DebugGL4(gl));

I also used built-in ShaderCode and ShaderProgram classes and added a trailing 'f' for the floating-point values in the shader code as recommended.

Interestingly, I had initially checked for compilation/linking issues with GL_COMPILE_STATUS in glGetShaderiv and GL_LINK_STATUS in glGetProgramiv in a previous version of the code, and it was returning GL_TRUE with the original shader code, so it seemed to have ruled out shader code as the problem.

Now I'm using the built-in classes; the shaders compile successfully on their own and the program still links just fine as before. In fact, it is working normally now without a real explanation as to why this is the case --both color and position modifications show up as expected.

This is the case even if the original shaders where the literals do not use the trailing 'f' are used, e.g.:

    gl_Position = vec4(0.0, 0.0, 0.5, 1.0);

The shaders were building before and they are building now. The only real difference is the Java code..

jmaasing wrote

Also, your shaders are not correct (on strict drivers they would not even compile I guess) since you use doubles when they should be floats, this is how it ought to be written:

gl_Position = vec4(0.0f, 0.0f, 0.5f, 1.0f);

I took a quick look at the GLSL 4 spec (https://www.opengl.org/registry/doc/GLSLangSpec.4.30.6.pdf), but I didn't immediately notice anything that would suggest shaders being invalidated by simply omitting the trailing 'f' in them. (I could've missed it since I didn't read the entire document, only read through some portions that seemed relevant.) Therefore, it seems the shader code itself was not the real source of the problem AFAIK (at least not for GLSL 4.4 core under GNU/Linux).

Do you have a reference where it's mentioned that GLSL literals must be written as such and that something different would be invalid?

I'm not exactly sure about the 'strict drivers'. I'm speculating a bit here, but when drivers implement the OpenGL/GLSL specs, the spec is responsible for stating what the result should be, unless we're talking about undefined behaviour. If the shader code is invalid, then it would not compile as shown below after intentionally messing up the vertex shader:

    Shader status invalid: 0(4) : error C0000: syntax error, unexpected '{', expecting "::" at token "{"

jmaasing wrote

If you look at the sample code I posted I use JOGL classes (ShaderProgram et c) to compile the shaders, they can help in presenting the compilation/linking errors.

I went through it again. It was very helpful, so thanks again.

jmaasing wrote

If you want to use glCompileShader straight up you really should check for GL errors after each step to verify that the shader compiled/linked.

I had done this, but I had not received errors for whatever reason. In fact, I'm still doing this in one of my other (broken) demos and this is how the error-checking code looks:

        int vertexShader = gl.glCreateShader(GL4.GL_VERTEX_SHADER);
        gl.glShaderSource(vertexShader, 1, vertexShaderSource, null);
        gl.glCompileShader(vertexShader);
        checkCompilationErrors(drawable);
        gl.glGetShaderiv(vertexShader, GL4.GL_COMPILE_STATUS, compiledVertShaders, 0);

        if(compiledVertShaders[0] == GL.GL_TRUE) {
            System.out.println("ok");
        } else {
            System.out.println("failed");
            printShaderLog(drawable, vertexShader);
        }

with the shader source code in this one being:

        ---- vertex shader ----

        #version 440 core

        void main(void)
        {
                gl_Position = vec4(0.0, 0.0, 0.5, 1.0);
        }

        ---- fragment ----

        #version 440 core

        out vec4 color;

        void main(void)
        {
                color = vec4(0.0, 0.8, 1.0, 1.0);
        }

and the 'checkCompilationErrors method being:

    private boolean checkCompilationErrors(GLAutoDrawable drawable) {
        GL4 gl = (GL4) drawable.getGL();
        boolean foundError = false;
        int glErr = gl.glGetError();

        while (glErr != GL.GL_NO_ERROR) {
            System.err.println("glError: " + glu.gluErrorString(glErr));
            foundError = true;
            glErr = gl.glGetError();
        }
        return foundError;
    }

The console output below says that things are "ok"...

        [info] Compiling vertex shader...ok
        [info] Compiling fragment shader...ok
        [info] GLSL source compilation status...ok
        [info] Creating GLSL program...ok

But this demo (which I'll refactor later) still behaves incorrectly by displaying the black pixel, even though it shouldn't be black.

A quick look at some of the JOGL code for compiling/linking the shader code seemed quite similar to what I was doing (aside from the object's internal state management and debug stuff). So it does not really explain the difference in behaviour to me.

I'm still not sure what I was (or was not) doing that was causing a problem. This is especially true given the working samples I've looked at which suggest that what I tried to do should've worked :(

jmaasing wrote

Note that there is a large difference in how "forgiving" drivers are with these kinds of errors, maybe your driver understands and compiles even though it strictly isn't correct. (another disclaimer; I'm stuck on Mac OpenGL 4.1 so maybe these things have changed in later versions).

That's an interesting note, though I tried 2 different drivers under 2 different OSes (GNU/Linux and (reluctantly) Windows 7). If it's true that a driver might be more 'forgiving' (which could be the case but would seem odd, given that they must adhere to the spec for compliance), then perhaps it's more of a vendor-specific (e.g. AMD vs NVIDIA) rather than a driver-specific detail(?)

I'm also not sure if the differences are due to GL 4.1 vs 4.4 updates or not. The last time I had used OpenGL was version 2.0 several years ago in C++ with the fixed pipeline, so I wouldn't know :)

jmaasing wrote

gouessej wrote

Yes, he should call glGetShaderInfoLog after compiling and glGetProgramInfoLog after linking, am I wrong?

Yeah, and also
"Each shader object has a boolean status, COMPILE_STATUS, that is modified as a result of compilation. This status can be queried with GetShaderiv"

Or simply use the very convenient JOGL classes

Yup, been there, done that :)
Not feeling closer to a root cause analysis (RCA) here :(

[EDIT1: Meme seemed fitting]
[EDIT2: Reduced meme image size]


I will start refactoring some of the other demos and report my findings as I make progress. Perhaps the reason for the issues will become apparent later (I hope). If you have any additional comments/suggestions, I'd appreciate them.

-------- Refactored/Working Demo3 Code for Simple Centered Pixel --------

/**
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */

package ray.cg.demos.demo3;

import java.nio.FloatBuffer;

import javax.media.opengl.DebugGL4;
import javax.media.opengl.GL4;
import javax.media.opengl.GLAutoDrawable;

import ray.cg.lib.DemoFrame;

import com.jogamp.opengl.util.Animator;
import com.jogamp.opengl.util.glsl.ShaderCode;
import com.jogamp.opengl.util.glsl.ShaderProgram;


public class Demo3 extends DemoFrame {

    private static final long serialVersionUID = 1L;

    private final Animator animator;
    private int program;
    private final int[] vertexArray;

    public Demo3() {
        super("Demo3: Ch2 Pg18");
        super.initOpenGL();
        setVisible(true);
        vertexArray = new int[1];
        animator = new Animator(canvas);
        animator.start();
    }

    @Override
    public void init(GLAutoDrawable drawable) {
        GL4 gl = (GL4) drawable.getGL();
        drawable.setGL(new DebugGL4(gl));
        program = createProgram(gl);
        gl.glGenVertexArrays(vertexArray.length, vertexArray, 0);
        gl.glBindVertexArray(vertexArray[0]);
    }

    @Override
    public void display(GLAutoDrawable drawable) {
        GL4 gl = (GL4) drawable.getGL();
        FloatBuffer color = FloatBuffer.allocate(4);
        color.put(0, (float) (Math.sin(System.currentTimeMillis()/100.0)*0.5 + 0.5));
        color.put(1, (float) (Math.cos(System.currentTimeMillis()/100.0)*0.5 + 0.5));
        color.put(2, 0.0f);
        color.put(3, 1.0f);
        gl.glClearBufferfv(GL4.GL_COLOR, 0, color);
        gl.glUseProgram(program);
        gl.glPointSize(60.0f);
        gl.glDrawArrays(GL4.GL_POINTS, 0, 1);
    }

    private int createProgram(GL4 gl) {
        String vertexShaderSource =
                "#version 440 core                              \n" +
                "                                               \n" +
                "void main(void)                                \n" +
                "{                                              \n" +
                "    gl_Position = vec4(0.0f, 0.0f, 0.5f, 1.0f);\n" +
                "}                                              \n";
        String fragmentShaderSource =
                "#version 440 core                              \n" +
                "                                               \n" +
                "out vec4 color;                                \n" +
                "                                               \n" +
                "void main(void)                                \n" +
                "{                                              \n" +
                "    color = vec4(1.0f, 1.0f, 1.0f, 1.0f);      \n" +
                "}                                              \n";
        String[][] sources = new String[1][1];

        sources[0] = new String[]{ vertexShaderSource };
        ShaderCode vertexShaderCode = new ShaderCode(GL4.GL_VERTEX_SHADER, sources.length, sources);
        boolean compiled = vertexShaderCode.compile(gl, System.err);
        if (!compiled)
            System.err.println("[error] Unable to compile vertex shader: " + sources);

        sources[0] = new String[]{ fragmentShaderSource };
        ShaderCode fragmentShaderCode = new ShaderCode(GL4.GL_FRAGMENT_SHADER, sources.length, sources);
        compiled = fragmentShaderCode.compile(gl, System.err);
        if (!compiled)
            System.err.println("[error] Unable to compile fragment shader: " + sources);

        ShaderProgram program = new ShaderProgram();
        program.init(gl);
        program.add(vertexShaderCode);
        program.add(fragmentShaderCode);
        program.link(gl, System.out);

        if(!program.validateProgram(gl, System.out))
            System.err.println("[error] Unable to link program");

        return program.program();
    }

    @Override
    public void dispose(GLAutoDrawable drawable) {
        GL4 gl = (GL4) drawable.getGL();
        animator.stop();
        gl.glDeleteVertexArrays(vertexArray.length, vertexArray, 0);
        gl.glDeleteProgram(program);
    }

    @Override
    public void reshape(GLAutoDrawable drawable, int x, int y, int width,
            int height) {
        GL4 gl = (GL4) drawable.getGL();
        gl.glViewport(x, y, width, height);
    }

    public static void main(String[] args) {
        new Demo3();
    }
}

I've updated the other demos and they're currently working as expected. This is good news for sure :)

However, what I'm now trying to do is figure out what the actual issue was before. I went through the code in some of the JOGL classes (e.g. ShaderCode, ShaderProgram, ShaderUtil) and, as far as I can tell, I was following a fairly similar process when creating the shader objects and program, checking for compilation/linking issues, and also for other errors with glGetError.

I was not immediately able to spot something that was being done internally in the JOGL classes that I was not already trying to do in previous attempts :/

Any tips to improve my understanding here would be appreciated. As I mentioned before, it seemed like it should've worked, but it didn't and I'm not yet clear why what was actually the case.

Thanks in advance.

Maybe look at the source code of Ardor3D, I couldn't use ShaderCode/ShaderProgram because it had to support several low level renderers and those high level classes would have driven the maintenance harder.

xghost wrote

I'm not exactly sure about the 'strict drivers'. I'm speculating a bit here, but when drivers implement the OpenGL/GLSL specs, the spec is responsible for stating what the result should be, unless we're talking about undefined behaviour. If the shader code is invalid, then it would not compile as shown below after intentionally messing up the vertex shader:

Not really, compliance means correct programs must compile. Compliance does not entail that incorrect programs must not compile. But basically nVidia, AMD and Apple drivers have very different behavior in dealing with incorrect programs.

There actually is a reference compiler but I haven't used it, on my ToDo-list :-)
http://www.khronos.org/opengles/sdk/tools/Reference-Compiler/

But you are right in that 1.0 is a float and should not compile differently than 1.0f. I was thinking of "1" as compared to "1.0", the first is interpreted as an int and not a float which is an error I often make :-)

As for why it works now and didn't work before I still don't know, please let us know if you figure it out :-) I'm betting it's a simple oversight or some simple thing that is done in a different order.

jmaasing wrote

please let us know if you figure it out :-) I'm betting it's a simple oversight or some simple thing that is done in a different order.

So I finally had more time to spend on this and I've figured out where the problem was. First, I'll just display the diff between what was not working and what is working, and then I'll explain where this actually originated.

First, the diff:

diff --git a/src/ray/cg/demos/demo4/Demo4.java b/src/ray/cg/demos/demo4/Demo4.java
index a59fb6a..9b2257e 100644
--- a/src/ray/cg/demos/demo4/Demo4.java
+++ b/src/ray/cg/demos/demo4/Demo4.java
@@ -101,7 +101,12 @@ public class Demo4 extends DemoFrame {
                System.out.print("[info] Compiling vertex shader...");

                int vertexShader = gl.glCreateShader(GL4.GL_VERTEX_SHADER);
-               gl.glShaderSource(vertexShader, 1, vertexShaderSource, null);
+               int[] lengths = new int[vertexShaderSource.length];
+               for (int i = 0; i < lengths.length; i++)
+                       lengths[i] = vertexShaderSource[i].length();
+
+               // install the vertex shader source to the shader object
+               gl.glShaderSource(vertexShader, vertexShaderSource.length, vertexShaderSource, lengths, 0);
                gl.glCompileShader(vertexShader);
                checkCompilationErrors(drawable);
                gl.glGetShaderiv(vertexShader, GL4.GL_COMPILE_STATUS, compiledVertShaders, 0);
@@ -115,10 +120,15 @@ public class Demo4 extends DemoFrame {

                System.out.print("[info] Compiling fragment shader...");
                int fragmentShader = gl.glCreateShader(GL4.GL_FRAGMENT_SHADER);
-               gl.glShaderSource(fragmentShader, 1, fragmentShaderSource, null);
+               lengths = new int[fragmentShaderSource.length];
+               for (int i = 0; i < lengths.length; i++)
+                       lengths[i] = fragmentShaderSource[i].length();
+
+               // install the vertex shader source to the shader object
+               gl.glShaderSource(fragmentShader, fragmentShaderSource.length, fragmentShaderSource, lengths, 0);
                gl.glCompileShader(fragmentShader);
                checkCompilationErrors(drawable);
                gl.glGetShaderiv(fragmentShader, GL4.GL_COMPILE_STATUS, compiledFragShaders, 0);

In short, it seems that the following approach was to blame: gl.glShaderSource(shader, 1, shaderSource, null); I had to change that line for the ones that you see above, particularly a different version of the same glShaderSource function: glShaderSource(shader, shaderSource.length, shaderSource, lengths, 0);

This originated by looking at the OpenGL Super Bible 6. In page 19, they have a working C++ example where glShaderSource(shader, 1, shaderSource, NULL) calls are used to provide the source for both the vertex and fragment shaders. Other JOGL-based notes that I was looking at were also following the same approach, based on the same reference and, AFAIK, were working fine for the note's author.

Clearly, the C++ samples do work because I was able to built and run them just fine. The author of the other notes I was checking out (a professor who teaches advanced computer graphics), who was using an older JOGL release and following the same approach based on the same reference, had no problems with this either. (I don't know which release he was using by date, but it must've been available during the Fall of 2013, definitely not the same March 2014 version I'm currently using --see previous posts.)

I'm wondering if something in JOGL changed in more recent releases that allowed this to work before, but not now? (The professor was using Windows, probably a 32-bit version, but not sure.)

I don't really have an explanation for this, but it seems that the previous approach should've worked just as well as the current one.

As shown by the diff, changing that in my demo is enough to make it work as intended, even though the previous approach worked correctly outside, and/or at least in previous releases of, JOGL.

I thought this behavioral difference could've been somewhere in the platform-specific native implementations, but I tested the code in both 64-bit GNU/Linux and 64-bit Windows 7 systems and did not see any difference.

Currently, one difference is the professor's machine was probably a 32-bit rather than a 64-bit system. (I've taken some courses with him in the past, and a laptop he was using was a 32-bit Windows 7 and I saw some JOGL-based demos running in it a few months ago, but I don't know that he was necessarily using the same laptop in 2013.)

Anyway, if anyone has any insight on why I've encountered this difference in the first place, please feel free to share. If this somehow happens to be a previously unknown issue somewhere (e.g. native implementations, something JOGL depends on and not JOGL itself, etc.), then please let me know too :)
 
Thanks.

[EDIT 1: Using the original call as gl.glShaderSource(shader, shaderSource.length, shaderSource, null); makes it work correctly in JOGL, though it's yet unknown why there's a difference between the JOGL-based behavior and the C++ code where the author uses the same call by sending a 1 instead and it still works.]

[EDIT 2: See picture from SB6 example.]

I haven't done C programming in nearly 2 decades so I don't know if that struct is considered one string or several. I guess it must only be null terminated once which means that there is only 1 element in the array.
When you send java strings I guess they are null terminated so there is more than 1 element.
Since they _are_ null terminated (I guess) you do not have to pass an array of string lengths and can use 'null' for the length array.
https://www.opengl.org/sdk/docs/man/html/glShaderSource.xhtml

jmaasing wrote

I haven't done C programming in nearly 2 decades so I don't know if that struct is considered one string or several.

It's a single string; there're no commas separating the lines, i.e., the entire thing will be printed if you simply do

printf("%s", vs_source[0]);

 Trying vs_source[1] will go out of range immediately.

jmaasing wrote

I guess it must only be null terminated once which means that there is only 1 element in the array.

This is correct. String literals are automatically null-terminated in C and C++, and due to the fact that the author does not separate the different lines (e.g. commas), there's only an array with a single null-terminated string.

jmaasing wrote

When you send java strings I guess they are null terminated so there is more than 1 element.

And this was, ultimately, the cause. A really minor oversight during code translation that became difficult to spot after the fact and sent me on a completely different path.

Anyway, it's a good thing that:

  1. The issue has been fixed
  2. The underlying cause was identified

Thanks for the help :)

I recently noticed that JOGL's ShaderCode class does not support tesselation control/evaluation shaders --only vertex/fragment/geometry shaders.



Am I supposed to use something else in JOGL for those shaders, or is that simply not supported yet? If not supported, does anyone know when support for them might become available? I'm not familiar enough with the JOGL code-base, so it seems unlikely to be as deceptively "simple" as adding the missing cases to this section.

It also seems to not support compute shaders. Any word on those? I'm sure I should still be able to work with the tess/comp shaders using the GL4 object directly (right?), but thought I'd ask.

Hi

Fill a bug report, it is a pertinent request for enhancement and it isn't very difficult to implement even though there is a bit more to do than adding several cases into a switch.

On 08/04/2014 10:30 AM, gouessej [via jogamp] wrote:
> Hi
>
> Fill a bug report, it is a pertinent request for enhancement and it isn't very
> difficult to implement even though there is a bit more to do than adding
> several cases into a switch.

Will add this feature.

You can support it by:
  - Adding a bug report as mentioned by Julian

  - Adding a most small test application
    w/ a tesselation control/evaluation shaders.
    This will allow me to swiftly add a unit test.

We did the same approach for adding geometry shader to JOGL,
so you help will be very much appreciated, 'xghost'.

~Sven

Sven Gothel wrote

Will add this feature.

You can support it by:
  - Adding a bug report as mentioned by Julian

  - Adding a most small test application
    w/ a tesselation control/evaluation shaders.
    This will allow me to swiftly add a unit test.

Hi Sven,

I tried to open an account with your Bugzilla instance, but the automatic email failed to reach me on both occasions. I did check my junk mail, but it's not there, so it might've failed to send it. Perhaps someone can take a look at it?

I should be able to provide you with what you need for this. I assume you'd need an application that actually does something (e.g. tessellated triangle, etc), i.e. not simply trying to create a ShaderCode object with GL4.GL_TESS_EVALUATION_SHADER as the type, correct?

Sven Gothel wrote

We did the same approach for adding geometry shader to JOGL,
so you help will be very much appreciated, 'xghost'.

~Sven

-Raymond ;)

On 08/05/2014 09:37 AM, xghost [via jogamp] wrote: We had troubles with google email before,
I notified them and it was fixed (?!) - at least for a while or some people.
The google issue was related to multidrop .. i.e. they don't comply w/
the email protocol. I elaborated on this somewhere ..

If this happened with a google account or any other provider,
please complain there.

I will assist here, i.e. copy our sendmail log regarding the attempt to send
it to you.

>
> I should be able to provide you with what you need for this. I assume you'd
> need an application that actually does something (e.g. tessellated triangle,
> etc), i.e. not simply trying to create a ShaderCode object with
> GL4.GL_TESS_EVALUATION_SHADER as the type, correct?

Since I have not used the tesselator myself, I trust you providing all we need
to make ShaderCode work fine.

So .. 'yes' :)

>
>     Sven Gothel wrote
>     We did the same approach for adding geometry shader to JOGL,
>     so you help will be very much appreciated, 'xghost'.
>
>     ~Sven
>
> -Raymond ;)

~Sven

I've added a new enhancement request[1]. I've also attached a .tar.gz file containing the following:

  1. The Java source code for a test case program;
  2. A screenshot of what it should look like when it works correctly.

The program makes use of tessellation control and tessellation evaluation shaders. You'll just need to update the package name.

Let me know if there're additional comments or questions.

Thanks.

[1] https://jogamp.org/bugzilla/show_bug.cgi?id=1043

There's also some odd behavior I've noticed when you have code that is trying to initialize OpenGL but suddenly need to exit. The following code easily reproduces the behavior:

@Override
public void init(GLAutoDrawable auto) {
	System.exit(0);
}

If the System.exit() method is called there, then the application won't exit; it will crash and actually to fail terminate. It cannot be terminated by clicking the X on the window frame or the IDE, either. The console log produced is:

X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 1/1, reusable (open, marked uncloseable): 0, pending (open in creation order): 1)
X11Util: Open X11 Display Connections: 1
X11Util: Open[0]: NamedX11Display[:0, 0x7fceacc23a70, refCount 1, unCloseable false]

You have to -SIGKILL it from the shell to close it down.

I'm wondering if others have seen this behavior (fairly easy to try out) or if there's a better/recommended way to actually handle the graceful exit part? I'm not sure I see a reason why trying to exit within the method should cause the observed behavior.

Please let me know if I should file a new issue.

Thanks.

On 08/22/2014 06:01 AM, xghost [via jogamp] wrote: I assume you use version 2.2.0?

Looks similar to an AMD Windows driver Bug 1028
<https://jogamp.org/bugzilla/show_bug.cgi?id=1028>.

At launch, we kick-off a SharedResourceRunner thread holding an
OpenGL context to probe capabilities.
If this is not properly shutdown, the AMD Windows driver keeps
the application from terminating. A driver bug.

System.exit(0) should cause our shutdown hook to be called, hmm.
Try GLProfile.shutdown() and then System.exit(0) - if you must.

Which OpenGL driver do you use ?

Maybe you can add a 'jstack -l PID >& jstack.log'
output to your new bug report.

Thank you.

~Sven

>
> Thanks.

Sven Gothel wrote

I assume you use version 2.2.0?

I tried it in the previous (i.e March 2014) release and also now in 2.2.0 (August 2014 release). It's the same behavior for both.

Sven Gothel wrote

Looks similar to an AMD Windows driver Bug 1028
<https://jogamp.org/bugzilla/show_bug.cgi?id=1028>.

I'm using a 64-bit GNU/Linux system and an NVIDIA card (GTX 770). I had taken a look at that bug before, but it seems unrelated.

Sven Gothel wrote

At launch, we kick-off a SharedResourceRunner thread holding an
OpenGL context to probe capabilities.
If this is not properly shutdown, the AMD Windows driver keeps
the application from terminating. A driver bug.

See previous data about OS/environment.

Sven Gothel wrote

System.exit(0) should cause our shutdown hook to be called, hmm.
Try GLProfile.shutdown() and then System.exit(0) - if you must.

I tried adding the GLProfile.shutdown() call first, but it made no difference. I still get the same result.

Sven Gothel wrote

Which OpenGL driver do you use ?

Currently using NVIDIA driver 331.38 for 64-bit GNU/Linux.

Sven Gothel wrote

Maybe you can add a 'jstack -l PID >& jstack.log'
output to your new bug report.

Thank you.

~Sven

Will do.

I've submitted a new bug report[1] and included the output of jstack as an attachment.

Thanks.

[1] https://jogamp.org/bugzilla/show_bug.cgi?id=1049