Hello,
I notice sometimes in GPU Trace a pipeline drain, where the number of unused warp slots shoots up to 100% in the middle of a drawcall or dispatch. This seems to be accompanied by a subchannel switch sync and a go idle sync
I am GPU-Tracing on a (plugged) RTX 3080Ti mobile, and no other application is running at the same time to fight for the GPU.
How can I go about identifying the reason behind this stall, it looks like it is caused by the subchannel switch? Since this happens in the middle of the dispatch/drawcall I believe it is not a compute/pixel shader change, could it a copy call?
Thank you,
Kostas
This looks like a context switch, probably from a different process. If you add to this the async copy engine activity and the pcie write traffic, I would guess dwm is transferring some display memory out of the GPU memory. do you know which GPU your display is connected to? if it’s mobile, it might not be connected directly to the gpu running the application.
Thanks for the reply, the laptop has an AMD Radeon GPU as well for the lighter tasks. I tried setting the RTX as the main GPU in both the Windows settings app and the NVidia control panel but didn’t make a difference.
What is interesting is that this stall happens twice in the frame
would the dwm transferring memory to the AMD GPU for display theory explain this?
Can GPU trace indicate when this context switch happens? Is it something that can be identified by NSight Systems perhaps?
This picture is harder to read because it doesn’t have the unit throughput snapshotted (nor the queue traces), (though I see a high PCIe bandwidth throughout).
would the dwm transferring memory to the AMD GPU for display theory explain this?
Twice in 3ms is unlikely. Something else might be running.
Can GPU trace indicate when this context switch happens? Is it something that can be identified by NSight Systems perhaps?
Nsight Systems would help cross-process analysis, yes.
