Skip to content

fix: resolve bandwidth for RTX Ada Generation laptop workstation GPUs#144

Open
devangpratap wants to merge 1 commit into
Andyyyy64:mainfrom
devangpratap:fix/ada-laptop-bandwidth-mobile-marker
Open

fix: resolve bandwidth for RTX Ada Generation laptop workstation GPUs#144
devangpratap wants to merge 1 commit into
Andyyyy64:mainfrom
devangpratap:fix/ada-laptop-bandwidth-mobile-marker

Conversation

@devangpratap

Copy link
Copy Markdown
Contributor

What

Fix memory-bandwidth resolution for the RTX Ada Generation workstation laptop GPUs (RTX 500 / 1000 / 2000 / 3000 / 3500 / 4000 / 5000 Ada Laptop). They all resolved to "BW: N/A" even though dbgpu already ships their bandwidth.

The cause is a word-order mismatch in _normalize_detected_name. The driver reports NVIDIA RTX 2000 Ada Generation Laptop GPU, which the normalizer turned into RTX 2000 Ada Generation Mobile (marker at the end). dbgpu names the same card RTX 2000 Mobile Ada Generation (marker in the middle). The two normalized strings never matched, so the dbgpu lookup fell through to None.

The fix relocates the Mobile marker to a trailing position inside _normalize_detected_name. Because the dbgpu index is built with the same normalizer, both the driver name and the dbgpu name now canonicalize to RTX 2000 Ada Generation Mobile and match. No bandwidth values are hardcoded; every card resolves from dbgpu's own data.

Why

These are common professional/mobile workstation cards. Without a bandwidth value the speed estimates fall back to a default, which produces worse recommendations for anyone on an Ada laptop. This is the same class of laptop-card bandwidth gap the resolver already guards against for consumer cards (issues #74, #61, #93).

Before:

RTX 500 Ada Generation Laptop GPU   -> None
RTX 1000 Ada Generation Laptop GPU  -> None
RTX 2000 Ada Generation Laptop GPU  -> None
RTX 3000 Ada Generation Laptop GPU  -> None
RTX 3500 Ada Generation Laptop GPU  -> None
RTX 4000 Ada Generation Laptop GPU  -> None
RTX 5000 Ada Generation Laptop GPU  -> None

After:

RTX 500 Ada Generation Laptop GPU   -> 128.0
RTX 1000 Ada Generation Laptop GPU  -> 192.0
RTX 2000 Ada Generation Laptop GPU  -> 256.0
RTX 3000 Ada Generation Laptop GPU  -> 256.0
RTX 3500 Ada Generation Laptop GPU  -> 432.0
RTX 4000 Ada Generation Laptop GPU  -> 432.0
RTX 5000 Ada Generation Laptop GPU  -> 576.0

The marker relocation is idempotent for cards that already carry a trailing marker, so consumer laptops (e.g. GeForce RTX 4060 Laptop GPU), the curated RTX A3000 Laptop entry, and all desktop cards are unchanged.

Testing

  • Tests pass (uv run pytest, 468 passing)
  • New tests added: one pins the whole Ada workstation-laptop family against dbgpu's values, one pins the normalizer behavior (mid-string marker relocated, trailing marker untouched)
  • Tested on real hardware: verified through resolve_detected_bandwidth (the same function hardware/nvidia.py uses for detected cards) against dbgpu's shipped specs; I do not have a physical Ada workstation laptop to confirm the end-to-end driver-name string

Notes

The change is a normalizer fix in hardware/gpu_db.py, not a new entry in the curated bandwidth table, since dbgpu already had the data and it was only unreachable due to naming.

The RTX 500/1000/2000/3000/3500/4000/5000 Ada Generation Laptop GPUs all
resolved memory bandwidth to None ("BW: N/A"), even though dbgpu already
ships their specs. _normalize_detected_name turned the driver name
"RTX 2000 Ada Generation Laptop GPU" into "RTX 2000 Ada Generation Mobile"
(marker last), while dbgpu names the card "RTX 2000 Mobile Ada Generation"
(marker mid-string), so the two never matched.

Relocate the Mobile marker to a trailing position in the normalizer. The
dbgpu index uses the same normalizer, so both orderings now converge and the
cards resolve from dbgpu's own data. The relocation is idempotent for cards
that already carry a trailing marker, so consumer laptops, the curated
RTX A3000 Laptop entry, and all desktop cards are unchanged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant