mirror of
https://github.com/Crosstalk-Solutions/project-nomad.git
synced 2026-10-17 13:19:18 +02:00
bf7e4b3b48
#1165 taught the benchmark path to reject an unresolved PCI id as a GPU model, but isUnresolvedGpuModel lived inside benchmark_service.ts and the Settings > System display path never learned the same thing. It still shows whatever lspci handed back. The two symptoms of a stale pci.ids database are independent, which is why the existing guard misses this. system_service already re-probes when a discrete-GPU controller reports an implausible BAR0 reading as VRAM, and that happens to fix the name as a side effect. But lspci can return a perfectly plausible VRAM figure alongside a name it could not resolve, and then nothing fires. Confirmed live on an AMD box. The Radeon 780M reports: model: "Device 1900", vram: 512 512 MiB clears the 256 MiB bogus-VRAM threshold, so no probe runs and the System page renders "Device 1900". The same box's Ollama startup log carries description="AMD Radeon 780M Graphics", so the probe the guard declined to run had the real name available the whole time. NVIDIA hides this because its path tends to be reached for other reasons; AMD has no equivalent. Adds an unresolved-name trigger alongside the VRAM one, and moves isUnresolvedGpuModel to app/utils/gpu_model.ts so the submission path and the display path share one definition instead of diverging again. Tests cover both placeholder shapes and, more importantly, a set of real product names that must never be rejected. Stacked on #1277, so the shared helper carries the WSL placeholders too. Closes #1196 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| eval | ||
| functional | ||
| standalone | ||
| unit | ||
| bootstrap.ts | ||