Group GPU scopes by Vulkan queues instead of CPU thread

[spnda]

With the current profiler, when I submit to two Vulkan GPU queues from 16 threads this will show 16 GPU timelines in the profiler for work to be done. However, I only have two Vulkan queues, and would like to see on which of these queues these operations are being executed. The GPU obviously doesn't care on which CPU thread the command buffer was generated on.

To me, it seems like the VkCtxScope constructor could just take an additional VkQueue handle and instead of writing the id of the current thread, we could write the queue handle. However, I'm not sure how Tracy internally handles the grouping of timelines so I don't know where to begin to make changes to support this. I'd also like to hear what other people think and if, perhaps, this functionality already exists but I just don't know about it.

[alvar-ava]

I have the same issue/feature request, but on D3D. On our project we're using fewer threads but more contexts. We don't have the info of the which queue a commandlist will be on when adding the marker, we only know the D3D command list at that point. The queue is determined when we do an ExecuteCommandLists on a queue. Perhaps an annotation function like the TracyD3D12NewFrame or similar could be added to indicate a "bin" or queue a certain tracy context should be sorted under.
Perhaps a function to set a "ContextTagName(context, name)" or similar, and a UI option to arrange the GPU scopes by "ContextTag" I think it would be sufficient, since I believe one context can only contain scopes on one single queue, else we would get into trouble with the Query readbacks.

The CPU thread division is also muddling things up a bit, and it would be good to be able to turn that off as a UI option