Supported process attribution and coverage/loss guarantees for WSL GPU-PV CUDA

Developer Tools Nsight Systems Profiling Linux Targets
1

I am looking for a supported, noninterrupting way to attribute CUDA activity in WSL2/Docker to exact guest processes while retaining visibility of competing CUDA contexts on the same physical GPU.

Retained environment: RTX 3060, Windows NVIDIA driver 591.86, and a prebuilt Nsight Systems 2025.6.1 Linux Target. These are retained versions, not a freshly checked installation. Raw nvidia-smi --query-compute-apps=pid,process_name,used_gpu_memory --format=csv,noheader,nounits returned empty rows during active workloads. A separate model-free fixture produced positive Nsight CUDA graph records despite empty NVML process rows. This demonstrates scoped trace visibility, but does not demonstrate a complete process census or zero loss.

The current Nsight guide describes system-wide CUDA injection as limited to eligible same-user processes launched after collection begins. The public GPU-PV description associates guest DXGPROCESS objects with the Windows vmmem process. Neither fact appears to supply a complete public observer join on its own.

Which supported interface and exact provider/event/API fields can provide the following on this platform?

  • A join between guest Linux PID, process lifecycle/start identity, VM identity, host DXGPROCESS/GPU context, and the physical GPU. What PID namespace or thread semantics apply?
  • Rundown and coverage of preexisting and newly created, uninstrumented compute contexts across Windows and WSL users, distinguishable from ordinary display activity.
  • Explicit dropped-event/buffer-loss and coverage diagnostics, including documented timestamp and observation-interval semantics.
  • The availability, privilege requirements, and an existing CLI example or export schema for RTX 3060 / driver 591.86 / WSL GPU-PV.

Can this be obtained without replacing the display driver, changing scheduler settings, or restarting Windows/WSL? If no supported interface provides these guarantees, an explicit statement of that limitation would also help us choose the next design step.

References:

2

What is the purpose of this? I ask because the only reason I can think of for this is an explicit violation of linux security protocols.

3

Thanks for asking. This is for fail-closed resource accounting on an owner-controlled Windows workstation, with a supervised CUDA job running in WSL2/Docker.

We need positive GPU activity attributable to our own job, plus authorized device-wide accounting that lets us reject the run when competing compute work makes isolation uncertain. Normal Windows display use should remain available.

The relevant information is process/context identity, lifecycle, resource usage and observation-coverage metadata. Application contents stay outside scope. We intend to use documented APIs/events under their normal OS permissions; denied access, unsupported joins or incomplete coverage would leave the run unqualified.

Which supported interface and permission model can provide this on RTX 3060 / WSL GPU-PV? If enumeration across users or VMs is deliberately unavailable, could you clarify that boundary and whether an administrator-authorized interface provides aggregate competing-compute detection? That would help us assess the supported limits without assuming a guarantee the platform does not offer.

4

Are you looking to have this running all the time? If so you are looking more for a monitoring tool (like DCGM) than for a performance profiling tool like Nsys.

I’m also going loop in @pkovalenko as our GPU hardware metric expert.

5

No, only during a short supervised CUDA job on my own PC. I need to confirm that job’s GPU activity and detect competing compute work. Does DCGM support this on RTX 3060 with WSL2/Docker?. Thanks for looping in the expert.