Bindless vertex array

I am trying to render vertices in bindless mode

I create each mesh and get their 64b vertex array pointer

https://github.com/elect86/NvGlSamples/blob/master/NvGlSamples/src/nvGlSamples/bindlessApp/util/Mesh.java#L80

Then, before the mesh.render() I set the attributes, enable it and its client state

https://github.com/elect86/NvGlSamples/blob/master/NvGlSamples/src/nvGlSamples/bindlessApp/util/Mesh.java#L115-140

and in the mesh.render() I set up the pointers to the vertices attributes

https://github.com/elect86/NvGlSamples/blob/master/NvGlSamples/src/nvGlSamples/bindlessApp/util/Mesh.java#L186-188

and then finally render

But I get this at the glDrawElements

Caused by: com.jogamp.opengl.GLException: element vertex_buffer_object must be bound to call this method
        at jogamp.opengl.gl4.GL4bcImpl.checkBufferObject(GL4bcImpl.java:39146)
        at jogamp.opengl.gl4.GL4bcImpl.checkElementVBOBound(GL4bcImpl.java:39197)
        at jogamp.opengl.gl4.GL4bcImpl.glDrawElements(GL4bcImpl.java:5440)
        at nvGlSamples.bindlessApp.util.Mesh.render(Mesh.java:223)

I guess (hope) this is a bug of jogl that doesnt take in account the bindless rendering and requires a vbo in anycase.. or?

On 04/20/2015 05:14 PM, elect [via jogamp] wrote: This is possible, AFAIK we had a bug fix in this regard.
Maybe similar to your other issue?
Can you create a unit test?
I have to see whether I can sneak this in these days,
otherwise it has to wait 1-2 weeks.
Surely this is a high prio bug.

~Sven

Sven Gothel wrote

This is possible, AFAIK we had a bug fix in this regard.
Maybe similar to your other issue?
Can you create a unit test?
I have to see whether I can sneak this in these days,
otherwise it has to wait 1-2 weeks.
Surely this is a high prio bug.

~Sven

Moin Sven,

I solved the other issues ^^ (for the moment) ^^

Anyway, you can clone my project, it is pretty small

https://github.com/elect86/NvGlSamples

 you have also to clone jglm and sdk

https://github.com/elect86/java-unofficial-opengl-SDK

https://github.com/elect86/Jglm

I like especially the part where you say this is an high priority bug :p

I really cant wait to get this shit working..!

Omg, it works!

Sorry I was using dsa in the wrong way, I fixed it and tried bindless vertex and element array, it works

I just have some problem of performances, I dont know what I changed that made they really bad compared to the C version, I hope I can solve, the profiler didnt help me that much in this sense, but anyway, we'll see

It would be very nice if you could write a simple example in pure JOGL with any third party library, we could put it into the wiki.

gouessej wrote

It would be very nice if you could write a simple example in pure JOGL with any third party library, we could put it into the wiki.

Sure, why not

I didnt solve my performance issues, I can write down some short tutorial, but I guess it is quite crap writing down a tutorial for fast rendering if the sample itself suxs..

Could you, guys, please take a look and check if you see anything wrong?

Is it faster with VBUM enabled?

gouessej wrote

Is it faster with VBUM enabled?

Yes, faster than without but much slower than C anyway, something like 200 vs 600 fps

I dont know what I changed and but it runs much slower :(

I isolated what makes my program slower

- in the initBindlessTextures() is the:

            gl4.glMakeTextureHandleResidentARB(textureHandles[i]);

- basically the whole

meshes[i].render(gl4);

in the draw(GL4 gl4) in the BindlessApp.java

- if I make vertex and index buffers resident

gl4.glMakeBufferResidentNV(GL4.GL_ARRAY_BUFFER, GL4.GL_READ_ONLY);

in the    public void update(GL4 gl4, ArrayList<Vertex> vertices, ArrayList<Short> indices) {

How may I debug/profile it?

It's a native method, isn't it??

gouessej wrote

It's a native method, isn't it??

Yes

I have some great news..

My code is running fast as hell on GPU

So the problem is on the cpu side (jogl/driver)

With the slowest rendering using:

- not bindless uniforms
- updating uniform every frame
- updating uniform for each mesh (building)
- not using (bindless) textures
- not using vbum

My whole rendering function takes, in average, 3987124 ns = 3987,1 us = 4,0 ms!

If we assume any other overhead equal zero, this would lead to 250 fps

The fastest rendering instead:

- with bindless uniforms
- updating uniform every frame
- updating uniform for each mesh (building)
- not using (bindless) textures
- by using vbum

takes, instead, an average of 1216558 ns = 1216,6 us = 1,2 ms!

This would mean, theoretically, 833 fps!


Ps: I am measuring time in this way

https://jogamp.org/bugzilla/show_bug.cgi?id=1167

Please use pure NEWT, no AWT, no bridge + call setExclusiveContextThread.

gouessej wrote

Please use pure NEWT, no AWT, no bridge + call setExclusiveContextThread.

gouessej wrote

Please use pure NEWT, no AWT, no bridge + call setExclusiveContextThread.

Ok, I got rid of jFrame and set exclusiveContext in this way

GLProfile gLProfile = GLProfile.getDefault();

        GLCapabilities gLCapabilities = new GLCapabilities(gLProfile);

        glWindow = GLWindow.create(gLCapabilities);

        newtCanvasAWT = new NewtCanvasAWT(glWindow);

        glWindow.setSize(1280, 720);

        glWindow.addGLEventListener(this);
       
        animator = new Animator(glWindow);
        animator.setModeBits(false, AnimatorBase.DEFAULT_FRAMES_PER_INTERVAL);
        animator.setExclusiveContext(true);
        animator.start();
       
        glWindow.setVisible(true);


Situation improved slightly (200+ fps)

If you really want to compare your stuff to something native without Java, don't use NewtCanvasAWT, just GLWindow.

gouessej wrote

If you really want to compare your stuff to something native without Java, don't use NewtCanvasAWT, just GLWindow.

I got rid of all awt

protected final void initGL() {

        GLProfile gLProfile = GLProfile.getDefault();

        GLCapabilities gLCapabilities = new GLCapabilities(gLProfile);

        glWindow = GLWindow.create(gLCapabilities);

        glWindow.setSize(1280, 720);

        glWindow.addGLEventListener(this);
       
        animator = new Animator(glWindow);
        animator.setModeBits(false, AnimatorBase.DEFAULT_FRAMES_PER_INTERVAL);
        animator.setExclusiveContext(true);
        animator.start();
       
        glWindow.setVisible(true);
    }

Anything else?

Ps: whenever I close it, on the dispose I call

        animator.stop();
        glWindow.destroy();

But I get this error anyway

Thread[main-Display-.x11_:0-1-EDT-1,5,main]: Warning: Default-EDT about (2) to stop, task executed. Remaining tasks: 1 - Thread[main-Display-.x11_:0-1-EDT-1,5,main]
X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 2/2, reusable (open, marked uncloseable): 0, pending (open in creation order): 2)
X11Util: Open X11 Display Connections: 2
X11Util: Open[0]: NamedX11Display[:0, 0x7fca400019a0, refCount 1, unCloseable false]
X11Util: Open[1]: NamedX11Display[:0, 0x7fca40017d40, refCount 1, unCloseable false]

Try to dispose the GLWindow before stopping the animator. I know that the animators are useful but I rarely use them. I'm not sure that the messages are really problematic.