mirror of
https://github.com/Crosstalk-Solutions/project-nomad.git
synced 2026-10-16 05:40:23 +08:00
Chris SherwoodandClaude Opus 5
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>
37 lines
1.9 KiB
TypeScript
37 lines
1.9 KiB
TypeScript
/**
|
|
* Is this GPU "model" a placeholder rather than a real name?
|
|
*
|
|
* systeminformation resolves PCI ids against the container's pci.ids database.
|
|
* When a card is newer than that file it reports the raw id verbatim — an RTX
|
|
* 5060 comes back as "Device 2d05". Vendor detection still succeeds, so these
|
|
* strings otherwise pass as legitimate model names.
|
|
*
|
|
* Deliberately narrow: it must never reject a real product name. No shipping
|
|
* GPU is called "Device" followed by four hex digits, and the Microsoft entries
|
|
* below are placeholder adapter names that appear nowhere outside a Windows or
|
|
* WSL graphics stack.
|
|
*
|
|
* Lives in its own module rather than beside its first caller because both the
|
|
* leaderboard submission path and the Settings > System display path need the
|
|
* same answer, and they diverged once already: #1165 fixed the submission and
|
|
* left the System page reporting the raw id (#1196). One definition, two
|
|
* callers, so the next placeholder shape only has to be added once.
|
|
*/
|
|
export function isUnresolvedGpuModel(model: string): boolean {
|
|
const s = model.trim()
|
|
if (s === '') return true
|
|
if (/^device\s+[0-9a-f]{4}$/i.test(s)) return true
|
|
if (/^unknown$/i.test(s)) return true
|
|
// WSL2 exposes the GPU through /dev/dxg rather than the real adapter, so
|
|
// si.graphics() reports Microsoft's generic placeholder even while CUDA work
|
|
// is running on a physical card. Left unhandled, an RTX 3090 reaches the
|
|
// public leaderboard labelled "Microsoft Basic Render Driver", which is worse
|
|
// than no label: it is wrong, and it fragments per-hardware grouping (#1218).
|
|
//
|
|
// These are Microsoft's own placeholder adapter names and appear nowhere
|
|
// outside a Windows/WSL graphics stack, so this cannot reject a real product
|
|
// name on a native Linux host.
|
|
if (/^microsoft basic (render driver|display adapter)$/i.test(s)) return true
|
|
return false
|
|
}
|