http://forum.jogamp.org/Bindless-vertex-array-tp4034343p4034456.html

It's not JOGL related, there is nothing showing that this performance problem comes from JOGL itself and you confirmed it:
http://jogamp.org/log/irc/jogamp_20150709050624.html#l70

The problem might come from NvInputTransformer or another class in your own code. Rather use a profiler. I'm going to close this bug report.

Reopen it if and only if a profiler shows an excessive GPU or CPU time consumption in JOGL.

Giuseppe, where can we find these Nvidia GL samples? The problem is that your code involves lots of classes, it's difficult to know what it implies.

It seems to be a problem in JOGL when the buffers are resident on the GPU:
http://forum.jogamp.org/Bindless-vertex-array-tp4034343p4034862.html

Created attachment 706 [details]
test.log

Commenting everything in the display. Comment also the part where you create the resident vbo and ibo buffers in the Mesh.update.

Run it, performances looks fine, I hits 5k fps 

Now comment out the resident vbo/ibo, you will see how performances will suffer from..

Please provide a unit test for JOGL for this case,
so we can validate this.
Best case: One unit test run w/o the performance loss,
and one proving the performance loss due to some GL functionality
you mentioned.
Thank you.

Created attachment 712 [details]
Program without NV resident buffers

Created attachment 713 [details]
Program with NV resident buffers

I commented most of the stuff, right now there is almost nothing in the display() except color/depth clearing, transformations and shader binding/unbinding, no draw calls at all.

What it matters now is only the declaration of resident NV buffers in the Mesh.update() method.

Program "without" has them commented, so no resident NV buffer will be created. In this way I hit more than 5k fps.

If I comment them out, program "with", I hit 600 fps, about 10 times less.. just having them declared, nothing else.

Please provide 'a unit test for JOGL' 
as requested and described in comment 6!

This includes either a git email patch or git pull request,
so I can nicely pull and merge it.

Thank you!

(In reply to comment #10)
> Please provide 'a unit test for JOGL' 
> as requested and described in comment 6!
> 
> This includes either a git email patch or git pull request,
> so I can nicely pull and merge it.
> 
> Thank you!

ZIP files w/ effort for me to reshape them manually
to suit our JOGL unit tests is _not_ acceptable here,
especially since you start to become a JogAmp developer 
who contributes w/ editing wiki, fixing bugs .. etc.

The content of attachment 712 [details] has been deleted by
    Sven Gothel <sgothel@jausoft.com>
who provided the following reason:

Provide unit test via git email-patch or git pull request.

The token used to delete this attachment was generated at 2015-07-28 17:19:02 CEST.

The content of attachment 713 [details] has been deleted by
    Sven Gothel <sgothel@jausoft.com>
who provided the following reason:

Provide unit test via git email-patch or git pull request.

The token used to delete this attachment was generated at 2015-07-28 17:19:36 CEST.

Please reopen this bug when a unit test as requested is provided
and the issue is valid and exists.

Hi Sven,

I created a minimal test case scenario to reproduce the bug

You can find it here, https://github.com/elect86/joglBug/blob/master/src/bug1167/Bug1167.java

If you comment out the two **INTERESTING** section, fps will drop from 9k to 400 fps (gtx 770).


Anyway I am afraid this test case won't be accepted, will it?

You said to provide it via git email-patch or git pull request. I don't know what you mean by "git email-patch". Regarding the latter instead, you mean directly on jogl github?

Probabily I found the issue, I'll be right back!

SO EXCITED!!!

(In reply to Giuseppe Barbieri from comment #16)
> Probabily I found the issue, I'll be right back!
> 
> SO EXCITED!!!

Please can you be more accurate about your findings? What is the culprit?

Briefly, if you iterate thousand of times this code

                gl4.glCreateBuffers(1, vertexBuffer, 0);

                // Stick the data for the vertices and indices in their respective buffers
                ByteBuffer verticesBuffer = GLBuffers.newDirectByteBuffer(512);
                gl4.glNamedBufferData(vertexBuffer[0],
                        verticesBuffer.capacity(), verticesBuffer.rewind(), GL_STATIC_DRAW);

        gl4.glBindBuffer(GL_ARRAY_BUFFER, vertexBuffer[0]);
        gl4.glGetBufferParameterui64vNV(GL_ARRAY_BUFFER, GL_BUFFER_GPU_ADDRESS_NV, vertexBufferGPUPtr, 0);
        gl4.glGetBufferParameteriv(GL_ARRAY_BUFFER, GL_BUFFER_SIZE, vertexBufferSize, 0);
        gl4.glMakeBufferResidentNV(GL_ARRAY_BUFFER, GL_READ_ONLY);
        gl4.glBindBuffer(GL_ARRAY_BUFFER, 0);

using always the same single array buffer vertexBuffer[0], then you get the slow down. Otherwise if you expand it and properly index it, it is gone.

Anyway, this does *not* reproduce also on C and Lwjgl, but this is something I'll investigate later.

Now I need to re-enable and re-validate all the other parts of the sample and be sure everything works

Relative good news and bad news here..


If I generate vertex and index buffers one by one (inside the two for loops), I get max ~ 600 fps. 
I can slightly improve it, if I generate them outside, I get max ~ 770 fps.

Code:
https://github.com/elect86/joglBug/blob/master/src/bug1167/jogl.java


But we are still faaar away from other platforms.

I built exactly the same program, same init(), same calls and same render() with just a clearBufferiv also on lwjgl and C. The former runs at 14k+ fps, the latter insanely crazy at 20k+.

There must be something wrong. I struggled on this bug for more than half an year thinking it was some bug inside the new extenstions.. but it's not.

What do you tell me, guys? :(

Glanced over the code, native-c code n/a though,
the only semantic difference seems to be that your JOGL code
uses GL context switches.
Therefor the NV GL driver penalties the switch, known by this vendor.

Our 'setExclusiveContextThread(..)' could remedy the situation.

If there is anybody willing to test this solution,
pls report - and if not working re-open this issue.