When do shader uniform values get uploaded compared to compute shader dispatch?

[scewpsdev]

Hey everyone.

I'm wondering when shader uniforms get uploaded to the GPU on the BGFX side.
So I've got a compute shader that reads from a dynamic vertex buffer with a fixed size. The amount of the buffer I want to process in the compute shader can change from frame to frame, which is why I pass the current length using a uniform vec4.
My issue is now that when I update the data, the buffer and uniform seem to get desynced, where the buffer data changes but the uniform containing the new length isnt updated yet. I verified this with RenderDoc, when the length changes from 2 to 3 for example, the first 3 elements of the array are valid data but the uniform still carries the length value of 2.

My setup looks like this:

[unrelated dispatch]
updating buffer data and uploading it
setting the uniform variable
setting the input compute buffers
compute dispatch
[unrelated dispatch]

Maybe the uniform only gets updated later when a draw call is submitted or something? Am I missing something obvious?

Edit: Also it seems to only happen in release builds.
Edit2: Nevermind, its also in debug builds for my other test case.

Hope you can help,

Scewps

[bkaradzic]

The best is to create simple repro case that demonstrates the issue you're having, instead explaining in text...

[bkaradzic]

Another thing to test is to set bgfx::setMarker and name each dispatch. Then look into RenderDoc.

[scewpsdev]

Yeah I've done that, thanks. I dug more into bgfx source code and stepped through the render thread code. Both constant buffer and vertex buffer are being uploaded correctly it seems. Very strange that the vertex buffer data reaches the GPU side but not the constant buffer... One thing I found curious is that CSSetConstantBuffers is called before updating its contents with UpdateSubresource, but I'm guessing CSSetConstantBuffers only passes the buffer by reference so it shouldn't matter?
Debugging this on two different machines with two different GPUs btw, so its not a machine specific issue. Also updated to the latest bgfx version, still the problem persists.. very strange.
Hopefully I wont run out of ideas

[scewpsdev]

Okay nevermind, it seems like I've caught the affected frame on the render thread and after the new vertex buffer data has already been sent to directx (when calling bgfx::update), bgfx reads the outdated uniform data from the uniform buffer.
Now I just have to figure out why theres still old data left in the buffer and where the new data ends up

[scewpsdev]

Another update. I've pinpointed the issue.
What was happening was that the uniform wasnt one frame delayed, the dynamic vertex buffer update was one frame too early.
Usually the buffer update is written to the command buffer m_submit->m_cmdPre, and only after the frame swap it reaches the render thread and is uploaded together with the constant buffers.
However the command buffer takes the memory by reference, and since I'm using makeRef the memory is never copied:
bgfx::update(lightBuffer, 0, bgfx::makeRef(lightBufferData, numVisibleLights * 2 * sizeof(Vector4)));
Since I preallocated and reuse the data array which I'm passing to the buffer, writing to it also affects the reference stored in the command buffer from the last frame, which is currently being consumed by the render thread in Context::rendererExecCommands(CommandBuffer& _cmdbuf).
Now when my data changes there is some chance that the vertex buffer update from last frame stored in m_render is still happening. And it will now use the brandnew data too early (should only be used next frame to keep synchronization with the constant buffers).
I thought I was being smart by preallocating the buffer and using makeRef, but apparently that's not something you should do since you don't know when the memory is actually being used. My solution was to allocate a new buffer every frame using bgfx::alloc instead. I honestly wanted to avoid allocating new memory every frame but I guess that's how I will do it until I find a better solution.
Thanks for the input and good work on the library btw @bkaradzic
Will mark this as solved 👍