testing nv command list

Hi All,

I’m beginning to play with this extension and tried to run the following code:

UniformAddressCommandNV u;
u.header = glGetCommandHeaderNV(GL_UNIFORM_ADDRESS_COMMAND_NV, sizeof UniformAddressCommandNV);
u.index = (unsigned short)materialUniLoc;
u.stage = glGetStageIndexNV(GL_FRAGMENT_SHADER);
u.addressLo = getAddressLo(myMeshes[n].uniformGPUAddr[MATERIAL_BUFFER]);
u.addressHi = getAddressHi(myMeshes[n].uniformGPUAddr[MATERIAL_BUFFER]);
glBindBuffer(GL_ARRAY_BUFFER, commandBuffer);
glBufferSubData(GL_ARRAY_BUFFER, 0, sizeof UniformAddressCommandNV, &u);
glBindBuffer(GL_ARRAY_BUFFER, 0);

GLintptr indirects[1];
GLsizei sizes[1];
indirects[0] = 0;
sizes[0] = sizeof UniformAddressCommandNV;

glDrawCommandsNV(GL_TRIANGLES, commandBuffer, indirects, sizes, 1);

The above code gives me an error, using the debug extension:
Type: Error; Source: API; ID: 1282; Severity: High
GL_INVALID_OPERATION error generated. Array object is not active.

However, if doing the line below instead it works OK.

glBufferAddressRangeNV(GL_UNIFORM_BUFFER_ADDRESS_NV, materialUniLoc, 
		myMeshes[n].uniformGPUAddr[MATERIAL_BUFFER], 0x10000/*sizeof(struct MyMaterial)*/);

From the spec these seem identical. Cn anyone help me with this?

Best regards,

António

Hi, it’s me again.

Just one more thing, what is the purpose of the stage field? And if the uniform buffer is used in multiple stages does that imply having as many commands?

Thanks again,

António

Maybe have a look at the open source nvpro-samples on that topic.
https://github.com/nvpro-samples

There are at least three examples using the NV_command_list extension.
https://github.com/nvpro-samples/gl_commandlist_basic
https://github.com/nvpro-samples/gl_commandlist_bk3d_models
https://github.com/nvpro-samples/gl_cadscene_rendertechniques

It’s recommended to go through the presentations listed on the gl_cadscene_rendertechniques README page!
http://on-demand.gputechconf.com/siggraph/2014/presentation/SG4117-OpenGL-Scene-Rendering-Techniques.pdf

Thanks for the reply.

I did go through those samples before I started :-)

I managed to get rid of the error thanks to Dark Photon (OpenGL boards) by binding a VAO before calling the command. It seems really weird having to bind a VAO for a command that is not supposed to require it.

Just one more thing, can you tell me if the above two excerpts of code should provide the same result? I got rid of the error but using the token produces a black figure, i.e. the buffer values are not getting to the shader. Using glBufferAddressRangeNV works fine so I know the buffer contents are OK.

Best Regards,

António

OK, I got it working as long as I do the actual drawing with the list. It seems that the bindings in the tokens are gone once the list is done. Is this the case?

Best Regards,

António

The draw calls to commandlist don’t know what you will do with them inside (could be written by GPU…) so it requires the state setup for the “maximum complexity” drawcall.

yes the state is always reset to whatever you provided via the api prior commandlist calls. This makes the drawcommands call rather heavy weight in terms of CPU validation.

The drawcommands call is supposed to do a lot of work to speed up hot loops. It is not a general replacement of the api.