Report real GPU memory on NVIDIA unified memory platforms

[sudoingX]

The problem

On UMA platforms such as DGX Spark, NVML returns NVML_ERROR_NOT_SUPPORTED for the framebuffer query, so nvtop falls back to the Linux system memory counters. The current fallback in set_unified_system_memory_info() reports:

total = MemTotal
used  = MemTotal - MemAvailable

Those describe the host, not the GPU. Measured on a DGX Spark (GB10, 121.690 GiB unified):

situation	NVML says the GPU holds	nvtop reports
idle GPU, 30 GiB of host allocations	nothing resident	34.375 GiB used
vLLM worker serving	89.276 GiB	98.695 GiB used

In the first case the GPU has nothing on it at all. In the second, nvtop overstates by more than 9 GiB of unrelated host consumption. The total also never moves off MemTotal, so the headroom figure ignores everything else on the machine.

This is the regression described in #449.

Reproducing without a DGX Spark

This needs no GPU workload. On any machine nvtop treats as unified memory, allocate and touch host memory:

b = bytearray(30 * 1024**3)
for i in range(0, len(b), 4096):
    b[i] = 1

The reported GPU used memory climbs with host consumption while the GPU stays idle.

The fix

NVML does report per-process allocations on these platforms even though it does not report a framebuffer size. Sum the compute and graphics allocations for the device and use that as the used memory, then report total as that sum plus MemAvailable, which is the memory the GPU can actually reach. MemAvailable alone becomes the free memory.

The change is confined to the existing if (has_unified_memory) branch. The dedicated framebuffer path is untouched.

Verification

Same Spark, model resident, reading NVML immediately before and after each nvtop sample:

NVML	nvtop
89.789 GiB	89.790 GiB
89.789 GiB	89.790 GiB
89.789 GiB	89.790 GiB

Also checked:

• builds clean with all backends enabled, no new warnings
• dedicated VRAM reporting verified separately on an RTX 5090
• process list, temperature, power and utilization panels unaffected
• RSS flat across 180 refresh cycles, the helper frees on both the success and failure paths

One note for review

The helper enumerates processes a second time per refresh. nvtop's order is refresh_dynamic_info, then get_running_processes, then fix_dynamic_info_from_process_info, and this code runs in the first phase, before the process list exists.

A tighter version would set only free_memory here and let fix_dynamic_info_from_process_info compute used from the already collected processes. That needs the shared needGPUMemory condition in extract_gpuinfo.c to stop requiring a valid total_memory first, which affects every vendor, so I kept this patch self contained. Happy to do it that way instead if you prefer.

Fixes #449