Fix both GPU readings on Apple Silicon

[sachinsachdeva]

Both GPU readings were wrong on M-series Macs. Neither was wrong in a way that looked broken, which is why they lasted: one was a plausible number that meant something else, and the other pinned high.

Reproduced and measured on an Apple M4 (10 cores, 16 GB) against synthetic Metal loads with known duty cycles.

GPU usage was effectively a yes/no answer

Device Utilization % is not a level. It is a span between reads: it reports on the time since the statistic was last read, and its denominator discounts time the GPU had nothing queued. So the width of that span decides what it says. Against a load busy exactly 47% of wall time:

Span between reads	Reports
50 ms	~50% (the true duty cycle)
100 ms	61%
300 ms	80%
500 ms	93%
once per update (shipped)	88–100%

Each update now takes one reading to re-base the statistic, then a burst of up to eight readings 50 ms apart, and averages those. Reading twice in quick succession is what turns "since you last looked" into a window of known width.

Nothing runs between updates. That is the load-bearing part of the design: every VS Code window runs its own extension host, so anything polling in the background multiplies by the number of open windows. An earlier revision of this PR did exactly that, and it was not acceptable:

Windows open	Background poller	Burst sampling (this PR)
1	7.6% of a core	2.3%
2	13.7%	3.4%
4	29.2%	6.9%

Those figures are for the whole extension, not just the GPU. No implementation trick rescued the poller — a persistent child process measured 18.8 ms per read against 17.5 ms for spawning each time, so the cost is inherent to reading the registry at intervals.

Burst sampling is both cheaper and more accurate than polling, because accuracy depends on the spacing within the measurement rather than on covering the whole interval.

A burst is unbiased but samples only a fraction of a second, so successive bursts are eased together to stop the figure jumping. The hover's peak is the burst's own and is not eased, so "is it busy right now" is answerable on the first update. Bursts are cut short as soon as the GPU reads idle, and sized against the update interval so they cannot make an update late.

GPU memory led with a figure that does not track GPU memory

The status bar showed In use system memory / Alloc system memory, which reads as used-out-of-total but is neither:

baseline            inUse= 1.05 GB   alloc= 3.60 GB
after +4GB private  inUse= 1.05 GB   alloc= 7.60 GB   <- exactly +4.00
after +2GB shared   inUse= 0.98 GB   alloc= 9.60 GB   <- exactly +2.00
after release       inUse= 1.10 GB   alloc= 5.56 GB

6 GB of real GPU allocation moved the displayed numerator by −0.07 GB, while the denominator was not a capacity at all — it was the actual usage.

The reading now shows the allocation against total system memory, which on unified memory is the pool it is genuinely drawn from. In use system memory is kept in the hover as "Mapped now", named for what it is. A discrete GPU, whose VRAM the registry does not report, shows the allocation with no total rather than a fabricated one.

Also fixed

• A switched-off GPU reading still cost a full sample every update. isShown() gathered the statistics before asking whether the reading was wanted. It now costs nothing — verified by counting ioreg invocations.
• A Mac listing an accelerator that reports no utilization ahead of one that does showed no GPU section at all — the parser stopped at the first statistics block and gave up if it lacked utilization.
• Name and core count are bounded to the node that supplied the statistics, so a neighbouring accelerator can no longer lend its name to another one's numbers.
• ioreg is invoked by absolute path, so a GUI-launched VS Code with an unusual PATH cannot silently lose the whole GPU section.
• The hover gains a peak figure alongside the average.

Verification

Accuracy, at the shipped 10 s update interval:

Regime	Truth	main	This PR
Idle	0%	0%	0.00%
Sustained load	100%	~100%	99%
50% duty cycle	47%	88–100%	settles ~57%, mean 49.6%
Memory, +5 GB held	+5.00 GB	+0.00 GB	+5.01 GB (3.55 → 8.56)

On the 50% load it reported 25 → 43 → 46 → 51 → 54 → 58 → 57 → 57 → 57 over 95 s, converging rather than jumping.

Cost, whole extension, shipped defaults:

	main	This PR
GPU idle	0.9% of a core	1.5%
GPU busy	0.8%	1.3%
GPU reading switched off	0.9%	0.8%

65 tests pass (up from 48), npm run lint clean, and the full extension was smoke-tested through a mocked vscode module — all five sections render and the host exits cleanly after dispose.

Known limitation

A burst samples a fraction of a second out of each update, so against genuinely intermittent work individual updates vary and the eased figure takes about three updates to settle after a change. The peak in the hover covers the immediate question. This is inherent to the only privilege-free source macOS exposes; powermetrics and IOReport need root or native code.

🤖 Generated with Claude Code