Repository navigation
feat(dash-tui): collect GPU/memory metrics in-process on Windows - #715
Open
juhovainio wants to merge 4 commits into
Open
juhovainio wants to merge 4 commits into
juhovainio wants to merge 4 commits into
Conversation
ROCMAI-564: the TUI's Windows client arm was a stub (no rocmdashd socket there yet), so Windows users saw no GPU/memory metrics at all. Add WinPerfCollector, reading the OS's own `GPU Engine`/`GPU Adapter Memory` performance counters via `Get-Counter` (the same WDDM/DXGK-backed source Task Manager's GPU tab uses) plus `Win32_VideoController` for adapter inventory/driver version. No AMD tool required. Mirrors amd_smi.rs's subprocess + pure-parse shape. client.rs's Windows connect_and_run now builds Snapshots in-process each tick from HostCollector (already cross-platform) + WinPerfCollector, feeding the same ClientMsg sequence the Unix socket arm produces, so the app loop doesn't need to know which platform it's on. Signed-off-by: Juho Vainio <juho.vainio@amd.com>
Required by ROCMAI-564's in-process Windows metrics ticker in crates/rocm-dash-tui/src/client.rs, which reuses HostCollector and WinPerfCollector directly instead of going through the daemon socket. Signed-off-by: Juho Vainio <juho.vainio@amd.com>
GPU Engine perf-counter instances are per-process on Windows 10/11 (pid_NNNN_luid_..._phys_0_eng_...), but GPU Adapter Memory instances are per-adapter only (luid_..._phys_0, no pid). device_key() keyed both verbatim, so every process using the GPU produced its own phantom near-zero device instead of aggregating onto the real adapter, which is why real hardware showed "Unknown GPU" with all-zero metrics despite `examine` detecting the GPU correctly. Confirmed against live Get-Counter output from a Strix Point laptop. Signed-off-by: Juho Vainio <juho.vainio@amd.com>
… calls Real hardware logs (Strix Halo) showed every tick timing out: "powershell Get-Counter query timed out" repeating for 20+ minutes straight, even though the identical script runs near-instantly when invoked manually. The bottleneck is powershell.exe child-process spawn latency, not the Get-Counter query itself, and it consistently exceeds the old 5s budget on real hardware. Bump RUN_TIMEOUT to 15s, and collapse the two independent metrics()/ system_info() spawns (each re-running the identical script) into one snapshot() call so each tick only pays the spawn cost once. Signed-off-by: Juho Vainio <juho.vainio@amd.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements ROCMAI-564
Windows has no
rocmdashdsocket yet, so the TUI's#[cfg(windows)]client arm now buildsSnapshots in-process on a 1-second ticker instead of connecting anywhere:HostCollector(already cross-platform) for CPU/memory, and a newWinPerfCollectorfor GPU utilization and VRAM, read from theGPU Engine/GPU Adapter MemoryOS performance counters viapowershell.exe(the same WDDM/DXGK-backed source Task Manager's GPU tab uses — no AMD tool required). The unix arm is unchanged.crates/rocm-dash-collectors/src/winperf.rs: newWinPerfCollector, parsing per-adapter utilization (max across engines) and dedicated VRAM usage, plus a best-effort adapter inventory (name/RAM/driver) forGpuSystemInfo.vram_total_mbis only filled in for the single-adapter case (the realistic integrated-APU target); multi-GPU hosts degrade to 0 rather than risk a wrong number, since correlating a perf-counter LUID to a specificWin32_VideoControllerentry isn't reliable without vendor-specific APIs.crates/rocm-dash-tui/src/client.rs: the#[cfg(windows)]connect_and_runnow drivesHostCollector/WinPerfCollectorand sends the sameClientMsgsequence (ConnectedthenEvent::Snapshot) the unix socket arm produces, so the app loop doesn't need to know which platform it's on.crates/rocm-dash-tui/Cargo.toml: adds therocm-dash-collectorspath dependency this requires.xtask/src/crate_edges.rs: allowlists the newrocm-dash-tui -> rocm-dash-collectorsfirst-party edge.Test plan
rocmdashddaemon running.cargo test(workspace, Linux) — newwinperfunit tests pass; no regressions.cargo clippy --workspace --all-targets— clean.