archdetect: detect Granite Rapids via CPU model when flags match Sapphire Rapids - #299
Draft
hmeiland wants to merge 2 commits into
Draft
archdetect: detect Granite Rapids via CPU model when flags match Sapphire Rapids#299hmeiland wants to merge 2 commits into
hmeiland wants to merge 2 commits into
Conversation
…hire Rapids eessi_archdetect.sh selects a microarchitecture purely from CPU feature flags. Intel Granite Rapids (Xeon 6) exposes the same visible /proc/cpuinfo flags as Sapphire/Emerald Rapids - its new features such as amx_fp16 are hidden by the kernel - so the flag match lands on x86_64/intel/sapphirerapids. Refine that match using the CPU model number, the only reliable Granite Rapids discriminator on Linux: once the flag match yields sapphirerapids, check the model and prepend x86_64/intel/graniterapids on family 6 / model 173 (0xAD, GNR-SP/AP) or 174 (0xAE, GNR-D). Non-breaking: cpupath -a returns a priority-ordered fallback chain and downstream subdir resolution selects the first path that exists, so Granite Rapids transparently falls back to sapphirerapids until a graniterapids build is shipped. Sapphire Rapids (model 143) and Emerald Rapids (model 207) are unaffected. Add a test fixture captured from a real Azure Standard_D2s_v7 (Intel Xeon 6973P-C, family 6 model 173). Verified on real Granite Rapids silicon and against the full archdetect fixture suite. Bump VERSION to 1.3.0.
boegel
reviewed
Sep 3, 2026
| local cpu_family=$(get_cpuinfo "cpu[ _]family") | ||
| local cpu_model=$(get_cpuinfo "model") | ||
| log "DEBUG" "cpupath: refining Sapphire Rapids match (family='$cpu_family', model='$cpu_model')" | ||
| # Intel family 6 models: 173 (0xAD) = Granite Rapids-SP/AP, 174 (0xAE) = Granite Rapids-D |
Contributor
There was a problem hiding this comment.
Do you happen to know an authoritative source for the mapping from model number to CPU family?
Would be nice to include that as a comment, for future reference...
Maybe https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/intel-family.h ?
Author
There was a problem hiding this comment.
Good call - yes, arch/x86/include/asm/intel-family.h is the authoritative source (it's what the kernel itself uses for model-based dispatch). The relevant entries:
INTEL_GRANITERAPIDS_X = IFM(6, 0xAD) -> family 6, model 173 (GNR-SP/AP)
INTEL_GRANITERAPIDS_D = IFM(6, 0xAE) -> family 6, model 174 (GNR-D)
(for contrast: INTEL_SAPPHIRERAPIDS_X = 0x8F/143, INTEL_EMERALDRAPIDS_X = 0xCF/207)
I've added a comment citing that file and the IFM() macros in 987faec. Thanks for the pointer!
… numbers Address review feedback from @boegel: document the model-number -> microarch mapping (family 6, models 0xAD/0xAE) with its source - the kernel's arch/x86/include/asm/intel-family.h (INTEL_GRANITERAPIDS_X/_D via IFM()).
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
2 participants
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
init/eessi_archdetect.shselects a CPU microarchitecture purely from the feature flags in/proc/cpuinfo. Intel Granite Rapids (Xeon 6) exposes the same visible flags as Sapphire/Emerald Rapids — its additions (e.g.amx_fp16,amx_complex) are intentionally hidden by the Linux kernel — so the flag match lands onx86_64/intel/sapphirerapids.This PR adds a small, targeted refinement: once the flag match yields
sapphirerapids, disambiguate using the CPU model number (the only reliable Granite Rapids signal on Linux) and prependx86_64/intel/graniterapidsto the match chain on:0xAD0xAEWhy it's non-breaking
cpupath -areturns a priority-ordered fallback chain, and downstream software-subdir resolution picks the first entry that actually exists in the repo. Until agraniterapidssoftware subdir is published, Granite Rapids transparently falls back tosapphirerapids(next in the chain). Sapphire Rapids (model 143) and Emerald Rapids (model 207) are unaffected — they don't match 173/174 and continue to resolve tosapphirerapids.Testing
tests/archdetect/x86_64/intel/graniterapids/Azure-Ubuntu24-6973P-C.{cpuinfo,output,all.output}, captured from a real AzureStandard_D2s_v7(Intel Xeon 6973P-C, family 6 / model 173).eessi_archdetect.sh cpupath→x86_64/intel/graniterapidseessi_archdetect.sh -a cpupath→x86_64/intel/graniterapids:x86_64/intel/sapphirerapids:x86_64/intel/icelake:x86_64/intel/cascadelake:x86_64/intel/skylake_avx512:x86_64/intel/haswell:x86_64/generictests/archdetectfixture: all pass, no regressions (Sapphire Rapids still →sapphirerapids).VERSIONbumped1.2.0→1.3.0.Notes
Granite Rapids has no dedicated software subdir in EESSI yet; this change makes archdetect ready to pick it up the moment one is added, and meanwhile keeps GNR on the correct
sapphirerapidsfallback. The model list generalises cleanly to future parts (e.g. a Diamond Rapids entry) should the same flag-aliasing recur.