[Feature]: GPU load graph (with multi‑GPU / Optimus MUX support)

Start by locating the sysinfo/system widget and its existing CPU load graph, then trace how platform-specific system metrics are collected. Compare the available Windows, macOS, and Linux GPU statistics APIs and determine how device selection and history should fit the current widget. Done means an agreed design and implementation path for GPU metrics, multi-GPU selection, and hybrid-GPU systems.

Feature description

Description

Wave’s sysinfo/system widget currently shows CPU load as a line graph, which is great—but for modern AI/agent workflows, GPU is often the primary bottleneck. It would be extremely useful to have a first‑class GPU load graph alongside (or instead of) CPU.

Requested features

GPU utilization graph

Per‑GPU load over time, similar in style to the existing CPU graph.
Ideally supports:
GPU utilization (%)
GPU memory usage
Optional: temperature, power draw, VRAM clock, etc.
Multi‑GPU & device selection

Ability to choose which GPU(s) to monitor when more than one is present.
Aggregate view (e.g., “All GPUs” or average) plus per‑GPU selection.
Optimus / MUX / hybrid‑GPU awareness

On systems with NVIDIA Optimus, MUX switches, or hybrid graphics (notebooks):
Allow explicit selection of the discrete GPU vs integrated GPU.
Don’t assume a single “primary” GPU; show whatever GPUs the OS/driver exposes.
This is important because on many laptops the discrete GPU is only active under load, and is the one agents actually use.
Configuration

Simple dropdown or settings panel under the sysinfo (or new “GPU” widget) to:
Enable/disable GPU graphs.
Select which GPU to graph.
Choose metrics (utilization, VRAM, temp, etc.).
Adjust time window / history length, similar to CPU.
Data sources / APIs

Windows: use vendor APIs (e.g., NVIDIA NVML) or OS performance counters for GPU stats.
Optional / stretch: read from third‑party tools (e.g., HWiNFO, vendor sensor services) if available, but native driver/OS APIs would be ideal.
Why this matters

LLMs and agents are GPU‑bound on most real workloads; tracking only CPU doesn’t tell you whether the system is actually saturated.
For notebook users with Optimus / MUX setups, being able to see which GPU is doing the work is critical—especially when debugging routing between iGPU and dGPU.
Having a built‑in GPU load graph keeps Wave as the central “control panel” instead of having to rely on separate tools.
Thanks for considering this—GPU visibility would make Wave significantly more useful for AI and dev workloads.

Implementation Suggestion

No response

Anything else?

No response