3
$\begingroup$

I'm rendering some UI using an immediate-mode UI library, so each frame it produces some meshes, which I then load into buffers and render, only to get some strange errors from Renderdoc:

You can see in the API inspector the list of calls preceding the draw.

I'm deeply puzzled by this, because of the following facts:

This problem only happens when the UI library returns more than one mesh. That is, the API calls for multiple meshes would go as follows:

// First mesh
glUseProgram
// set textures
// bind vertex array
glNamedBufferData // for the vertex buffer
glNamedBufferData // for the index buffer
glDrawElements

// Second mesh
glNamedBufferData // for the vertex buffer
glNamedBufferData // for the index buffer
glDrawElements

...    

If I call glVertexArrayVertexBuffer even once per frame, the errors are not reported, regardless of how many meshes the UI returns. First mesh draw: Second mesh draw:

Why I find this strange:

  1. The vertex array object is fully set up at the start of the program, including the call to glVertexArrayVertexBuffer, and the binding of vbo to vao is never supposed to change, together with offset and stride.
  2. I removed every other draw call from the program for testing and left only those for the UI, so nothing should interfere
  3. The UI renders just fine in the program, it's only RenderDoc that complains

I see 2 possibilities - 1) I am using the API incorrectly, and 2) there's a bug in RenderDoc.

Would really appreciate if someone could shed some light onto this issue.

UPDATE:

Nicol Bolas commented below

"including the call to glVertexArrayVertexBuffer" Are you sure about that?

I have captured Frame #0 and Frame #1815 in Renderdoc to illustrate that the call is made (see the image below) and noticed that in the second frame no errors were reported! It strongly suggests that if Frame #0 is not captured, then Renderdoc just doesn't know that the appropriate calls have been made and reports false errors.

Also quite expectedly, if I remove the call to glVertexArrayVertexBuffer, then nothing gets drawn and OpenGL complains. I almost think we've solved the mystery.

UPDATE 2.

As per Nicol Bolas's suggestion I have rewritten the code so that all the meshes are packed into one vertex buffer and are loaded there once per frame. After this change Renderdoc stopped complaining. I mostly consider the issue solved, but one thing is still not clear:

If the assumption that Renderdoc needed Frame #0 to "know" about the call to glVertexArrayVertexBuffer is correct, then why did it not complain when there was only 1 mesh to draw (i.e. there were no multiple draw calls with glNamedBufferData between them).

If no one knows for sure why this is happening, I will probably raise an issue with Renderdoc and mark this question as done.

$\endgroup$
6
  • 1
    $\begingroup$ "including the call to glVertexArrayVertexBuffer" Are you sure about that? $\endgroup$ Nov 6 '21 at 18:10
  • 1
    $\begingroup$ It should be noted that uploading to a region of a buffer immediately after issuing a call that reads from that buffer is a bad idea for performance. I know you're re-specifying the buffer with BufferData each time, but it's still much better to allocate a big slab of memory, do a single upload to it per-frame, and then do a bunch of draw operations from it. $\endgroup$ Nov 6 '21 at 18:17
  • $\begingroup$ @NicolBolas thank you for your comment. I have updated the post with more info, which may explain what's going on. I also appreciate your note about performance and I will change it so that all the meshes are put into a single buffer once per frame. $\endgroup$ Nov 6 '21 at 22:18
  • 1
    $\begingroup$ And where is your glCreateVertexArrays call? $\endgroup$ Nov 6 '21 at 22:21
  • $\begingroup$ @NicolBolas I'm very new to Renderdoc so took me a while to find it - it seems it puts all initialization calls into a separate window - I've updated the screenshot with the call highlighted. Thanks! $\endgroup$ Nov 6 '21 at 22:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.