GPU tracing breaks when paired with a rendering layer that submits calls out of order

[BSVino]

I use bgfx as a rendering layer and with bgfx you can submit draw calls in any order and it will reorder your draw calls to optimize submission, for example by grouping materials to reduce switches. However, if I add GPU traces (TracyGpuZone) for anything but the highest level of drawing then it causes the tracy profiler client to crash as it receives signals. If I move the trace markups to be inside bgfx then I lose the semantic information about what is being rendered, which is much less useful. It would be nice if Tracy could understand that a single draw call/zone may correspond to multiple GPU sections.

(Love tracy btw it's great.)

[wolfpld]

I'm not sure what you want to get here. TracyGpuZone is used for OpenGL markup and OpenGL command submissions are not reorderable. Using this macro in context of any other functionality is not supported.

[axelkinner]

Hi, I’m likely experiencing the same issues with tracy gpu profiling. I think that our issue is that we record command lists on several threads and the begin and end of a "zone" might not be on the same thread or command list. and my example below 4 d3d12 command_lists on 4 different threads to reduce the CPU overhead. A-K is different d3d12 commands and the horizontal position corresponds to it's execution in time.

t0, [push("gbuffer"), A,     B,    C]
t1, [ D,    E,  pop("gbuffer"), push("lighting"), F, G]
t2, [ pop("lighting"), H,    I]
t3, [ J,          K]

And when we submit them in order [A, B, C][D , E, F, G][H, I][J, K] Tracy Profiler then usually asserts on assert( !td->second.stack.empty() ); in function void Worker::ProcessGpuZoneEnd( const QueueGpuZoneEnd& ev, bool serial ). In my case I believe the error I get corresponds to t1 or t2 where a pop is executed without a corresponding push, since it looks like tracy profiler only accessing thread data and want to access the corresponding push data.

Meaning that my guess is that it can't handle that the zone begin/push and zone end/pop is on different threads and perhaps when executed in different order? I have not yet dug that much into the code of the profiler, but so far I have tried the D3D12 header and the C-api and got the same error so far. Note that I also had to modify the D3D12 code so I can manually start and end a zone in order for this to work in our engine.