Fix: resolve AMD GPU name mismatch between dashboard and monitoring via PCI BDF#1268
Conversation
…ia PCI BDF On Windows AMD systems, the dashboard GPU info names come from DXGI (e.g. "AMD Radeon RX 7900 XTX") while monitoring event names come from ADL (e.g. "Radeon RX 7900 XTX"). This name mismatch caused GPU temperature to not display on the dashboard, even though Insights (which uses ADL names consistently) showed it correctly. Introduce a SetupDi-based provider that enumerates display adapters with their PCI Bus/Device/Function addresses and device descriptions (which match DXGI names). ADL adapters now expose BDF alongside their metrics, enabling reliable cross-API GPU identification. The ADL name is resolved to the canonical DXGI name via BDF lookup at the monitoring boundary, so names are consistent throughout the entire data flow.
Coverage Report
File CoverageNo changed files found. |
There was a problem hiding this comment.
Pull request overview
This PR fixes AMD GPU metric display on Windows by ensuring GPU names are consistent between the dashboard (DXGI) and monitoring (ADL) paths, using PCI Bus/Device/Function (BDF) to correlate adapters.
Changes:
- Add a Windows SetupDi-based provider to enumerate display adapters with PCI BDF + device description (DXGI-style name).
- Extend ADL per-adapter monitoring metrics to include PCI BDF and resolve ADL names to canonical DXGI names via BDF lookup.
- Update dashboard GPU temperature selection to prefer exact GPU name matching with a fallback.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| src/features/hardware/dashboard/components/DashboardItems.tsx | Updates GPU metric selection logic to rely on consistent backend-resolved GPU names (with fallback). |
| src-tauri/src/services/monitoring_service.rs | Adds BDF→DXGI-name cache and uses BDF-based correlation when assembling AMD GPU samples. |
| src-tauri/src/infrastructure/providers/windows/setupdi_provider.rs | New SetupDi enumeration provider returning adapter description + PCI BDF for cross-API identification. |
| src-tauri/src/infrastructure/providers/windows/mod.rs | Exposes the new setupdi_provider module on Windows. |
| src-tauri/src/infrastructure/providers/windows/adl_provider.rs | Adds BDF fields to adapter state and introduces AdlAdapterMetric for per-adapter usage/temperature results. |
| src-tauri/Cargo.toml | Enables winapi features needed for SetupDi/DEVGUID access on Windows. |
Rust Backend Coverage ReportCoverage Details |
- setupdi_provider: check GetLastError() for ERROR_NO_MORE_ITEMS to distinguish enumeration end from unexpected errors in SetupDiEnumDeviceInfo - setupdi_provider: extract read_registry_string() helper that retries with a dynamically allocated buffer when the fixed-size stack buffer is too small (ERROR_INSUFFICIENT_BUFFER) - monitoring_service: switch bdf_to_dxgi_name from std OnceLock to tokio OnceCell with spawn_blocking so the blocking SetupDi calls never stall an async worker thread - DashboardItems: guard against empty gpus array and add optional chaining on the element access
…atting function parameters
- setupdi_provider: remove unused `log_internal` import that would fail `clippy -D warnings` in CI - DashboardItems: restrict fallback to single-GPU + single-metric case to avoid showing another adapter's metrics on multi-GPU systems - monitoring_service: log JoinError explicitly in bdf_to_dxgi_name instead of silently swallowing it via unwrap_or_default - monitoring_service: fetch BDF→name map once before the loop instead of awaiting resolve_gpu_name per iteration - monitoring_service: extract resolve_gpu_name_from_map as a pure function and add 4 unit tests covering hit, miss, multi-BDF disambiguation, and duplicate-entry behavior
…hub.com/shm11C3/HardwareVisualizer into fix/amd-gpu-temp-dashboard-bdf-matching
Co-authored-by: Copilot <[email protected]>
…try property retrieval
Co-authored-by: Copilot <[email protected]>
| wmi = "0.18.3" | ||
| dxgi = "0.1.7" | ||
| winapi = { version = "0.3", features = ["dxgi"] } | ||
| winapi = { version = "0.3", features = ["dxgi", "setupapi", "devguid"] } |
There was a problem hiding this comment.
setupdi_provider.rs imports additional WinAPI modules (um::errhandlingapi, um::handleapi, plus shared::minwindef/shared::winerror). The winapi dependency here only enables dxgi, setupapi, and devguid, so the build can become brittle if those extra module features aren’t pulled in transitively. Consider explicitly enabling the needed winapi features (e.g., errhandlingapi, handleapi, minwindef, winerror) or switching those calls to the already-enabled windows crate APIs to avoid feature-gate compile failures.
| winapi = { version = "0.3", features = ["dxgi", "setupapi", "devguid"] } | |
| winapi = { version = "0.3", features = ["dxgi", "setupapi", "devguid", "errhandlingapi", "handleapi", "minwindef", "winerror"] } |
Summary
On Windows AMD systems, the dashboard GPU info names come from DXGI (e.g. "AMD Radeon RX 7900 XTX") while monitoring event names come from ADL (e.g. "Radeon RX 7900 XTX"). This name mismatch caused GPU temperature to not display on the dashboard, even though Insights (which uses ADL names consistently) showed it correctly.
Introduce a SetupDi-based provider that enumerates display adapters with their PCI Bus/Device/Function addresses and device descriptions (which match DXGI names). ADL adapters now expose BDF alongside their metrics, enabling reliable cross-API GPU identification. The ADL name is resolved to the canonical DXGI name via BDF lookup at the monitoring boundary, so names are consistent throughout the entire data flow.
Related Issues
Type of Change
fix/branch)feat/branch)refactor/branch)docs/branch)chore/branch)Screenshots / Videos
Test Plan
Checklist
npm run lint && npm run format/cargo tauri-lint && cargo tauri-fmt)npm test/cargo tauri-test)