Help with NV_command_list

(Development environment is Linux Mint with beta driver 349.12; GPU is a GTX 760).

Having some trouble using the new NV_command_list extension. I’ve got a draw function that looks a bit like this:

glBindFramebuffer(GL_READ_FRAMEBUFFER, 0);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo);

// clear:
glClearColor(1, 0, 0, 0);
glClearDepth(1.0);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

// draw:
glDrawCommandsStatesAddressNV(…);

// blit:
glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);

glBlitFramebuffer(0, 0, width, height,
0, 0, width, height, GL_COLOR_BUFFER_BIT, GL_NEAREST);

Having trouble getting it to do much. I can’t get the commands for the geometry that I want to draw anything but a blank frame, but even if I fill a command buffer with a single NOP command, then I see the screen clear to red for the first frame, and all subsequent frames are black (same thing happens with the ‘real’ commands I want to try, or commands that just set the uniform buffer addresses but without any draw commands). I’d expected that with a single NOP command, the glDraw() command would ‘do nothing’ and I’d always see the frame cleared to red, but that seems to only happen for the first frame only.

I’ve tried removing the glDrawCommands and things work as they should - every frame is cleared to red, so the clear and blit seems to be working.

Anyone know what might be going on? Does a command buffer always need an actual draw command or a terminate or something somewhere in it? I am only trying to use the glDrawCommandsStatesAddressNV() and not the compiled command lists (which really wouldn’t be appropriate for this application). I have added debugging callbacks with glDebugMessageCallback but that doesn’t tell my I’m doing anything wrong (it does tell me things about the buffers I’ve created for storing geometry, I and I can do incorrect things deliberately, like not setting a framebuffer when capturing the state, and the debug extension reports errors). The gl_commandlist_* samples posted on github do work for me. I’m using SDL as the windowing environment.

– Alex

So what I’ve discovered since posting this and hacking on the NV_command_list examples that were posted on github:

• If in, say, basic-nvcommandlist.cpp, I remove the code that renders the user interface (TwDraw()), I see behavior similar to what I posted about originally - the first frame of the sample renders correctly, the contents of all subsequent frames are whatever the default framebuffer had been cleared to (as if the blit didn’t happen at all).

• If I remove the call to TwDraw() and insert some old time OpenGL code before or after the blit:

{
      NV_PROFILE_SECTION("Blit");
      glBindFramebuffer(GL_READ_FRAMEBUFFER, fbos.scene);
      glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
 
      glUseProgram(0);
      glBegin(GL_POINTS);
      glVertex3f(0, 0, 0);
      glEnd();
 
      glBlitFramebuffer(0,0,width,height,
        0,0,width,height,GL_COLOR_BUFFER_BIT, GL_NEAREST);
    }

…then the example works fine (sans UI; and for that matter, my own program works correctly after inserting this hack)

Hi,
That is correct. I recently bumped into this issue while trying to make “gl_commandlist_bk3d_models” work under Linux. I canceled additional UI/overlays for simplifying the tests, drawing command-lists only… which exposed this bug to me.

The good new is that I narrowed down the issue in the driver and filed a bug few days ago. The fix is in the driver source code as we speak.
Next Beta versions and next official drivers will have the fix.

Sorry for the inconvenience!
Tristan

Ah great, thank you. I did take this up on a forum at OpenGL.org, and someone there actually hadn’t had these problems with their Linux setup:

– Alex

Hi,

We have a similar issue with one of our Maya plugin using NV_command_list.
When we use the extension, the Maya UIs using OpenGL in different windows are not redrawn.

I am using Driver Version: 418.74 on linux centos 7.4.

Was the fix deployed in the driver ? How can we assess this is the same bug ?

Thanks,

Cyril