I’m beginning to play with this extension and tried to run the following code:
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]);
glBufferSubData(GL_ARRAY_BUFFER, 0, sizeof UniformAddressCommandNV, &u);
indirects = 0;
sizes = 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.
myMeshes[n].uniformGPUAddr[MATERIAL_BUFFER], 0x10000/*sizeof(struct MyMaterial)*/);
From the spec these seem identical. Cn anyone help me with this?
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 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.
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?
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.