Strange issues

[elect]

I am experiencing a strange behaviour with my lwjgl test bench..

At first it runs extremely fast (up to 2.5k fps) for about the first second and then it runs as expected, just a little slower than the counterpart jogl

It behaves the same whenever the window loses the focus, extremely fast and then as expected

Moreover, whenever I press esc, it takes 7/8 second before it actually quits..


What could be?

[Kai]

Why is your glfwSwapBuffers() call commented out? You must swap the buffers or else you will feed the OpenGL driver with an enourmous amount of draw calls and never end the frame.

If you plan on measuring the overhead of a GL call, as the name of your class indicates, then this is really difficult to do, since the overhead of a particular call really depends on the current GL state. You could however measure a simple JNI call overhead instead, which is roughly somewhere around 25 CPU clock cycles for an invocation of a method with a single long parameter and an int return value.

I did a test on Win7 x64, jre 1.8.0_51 with a simple JNI function just returning its long parameter casted to int. The result was that it could do rougly about 144,800,000 invocations per second (which is surprisingly good). Assuming the CPU ran at max turbo speed at 3.7GHz while performing the test, this would mean roughly a cycle count of: (3.7E9 [cycles/sec] / 144,800,000 [inv/sec]) ~= 25 [cycles/inv]

[elect]

Why is your glfwSwapBuffers() call commented out? You must swap the buffers or else you will feed the OpenGL driver with an enourmous amount of draw calls and never end the frame.

Because I didn't need that. I thought the draw call was enough to flush the pipeline..

Anyway, you were right, now it looks fine, thanks Kai.

If you plan on measuring the overhead of a GL call, as the name of your class indicates, then this is really difficult to do, since the overhead of a particular call really depends on the current GL state.

Yep, but I always take the worst case scenario, so I force the i-th specific GL state to change.

I should have written that better, the point is to calculate the relative weight between different state changes, in order to design a rendering pipeline accordingly

You could however measure a simple JNI call overhead instead, which is roughly somewhere around 25.55 CPU clock cycles for an invocation of a method with a single long parameter and an int return value.

I did a test on Win7 x64, jre 1.8.0_51 with a simple JNI function just returning its long parameter casted to int. The result was that it could do rougly about 144,800,000 invocations per second (which is surprisingly good). Assuming the CPU ran at max turbo speed at 3,7GHz while performing the test, this would mean roughly a cycle count of: (3.7E9 / 144,800,000) = 25.55

Interesting, however this is likely to be hidden if the app is not cpu limited, or like HScottH wrote, under 50% load.