Add GFX IP version fallback for GPU family detection#178
Open
mgajda wants to merge 3 commits into
Open
Conversation
When a GPU's PCI device ID is not in the r600_pci_ids.h table, fall back to querying the GFX IP version from amdgpu and mapping it to a family. This allows radeontop to recognize newer GPUs (RDNA 3, 3.5, 4, 4m, 5) without needing a PCI ID table update for every new SKU. New families: MENDOCINO, GFX1033, GFX1034, NAVI31, NAVI32, NAVI33, GFX1103, GFX1150, GFX1151, GFX1170-1172, GFX1200-1201, GFX1300, GFX1310. Unknown GFX codes fall back to the base family for their major.minor version (e.g. any GFX11.0.x maps to NAVI31).
mgajda
force-pushed
the
gfx-fallback-detection
branch
from
c4f5225 to
44ae837
Compare
This was referenced Apr 14, 2026
The GC (Graphics & Compute) block number queried via amdgpu_query_hw_ip_info() comes straight from the chip and is unambiguous, while PCI device IDs are reused by AMD across APU SKUs (e.g. 0x150E is shared by Strix Point gfx1150 and Krackan Point gfx1152 - only the GC number distinguishes them). When both are available, the GC number wins. Legacy cards (radeon driver, or amdgpu without IP query support) report gfx_version == 0 and fall through to the PCI lookup, so this is backwards-compatible.
When the GC (Graphics & Compute) block number is reported by
amdgpu but doesn't map to a known family, print both:
gfx1152? (GC 11.5.2 unknown)
The GC number is what we know for certain (queried straight from
the chip); the GFX shader target is a putative guess because for
GC 11.0.x the GC rev and GFX number diverge (GC 11.0.1 = Phoenix
gfx1103, not gfx1101). The '?' suffix marks the GFX side as
uncertain so the user can search for either string when looking
up the chip.
mgajda
added a commit
to mgajda/radeontop
that referenced
this pull request
May 13, 2026
When the GC (Graphics & Compute) block number is reported by
amdgpu but doesn't map to a known family, print both:
gfx1152? (GC 11.5.2 unknown)
The GC number is what we know for certain (queried straight from
the chip); the GFX shader target is a putative guess because for
GC 11.0.x the GC rev and GFX number diverge (GC 11.0.1 = Phoenix
gfx1103, not gfx1101). The '?' suffix marks the GFX side as
uncertain so the user can search for either string when looking
up the chip.
Same fix is on the gfx-fallback-detection branch (PR clbr#178); the
two PRs will absorb the duplicate via squash-on-merge.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
amdgpu_query_hw_ip_infoduring initr600_pci_ids.h, fall back to GFX version to identify the GPU familyhw_ip_version_minoron GFX11+ kernelsNotes
r600_pci_ids.h— PCI ID table updates are a separate MRinitbits()— RDNA+ bit layout corrections are a separate MRamdgpu_read_mm_registersaccess are confirmed correct across GFX10–GFX12 via kernel headersTest plan
ENABLE_AMDGPU=1(requires libdrm_amdgpu)amdgpu=0) —gfx_versiondefined in detect.c, stays 0