Repository navigation
feat(rocr,clr): Add gfx1170, gfx1171 target support - #11715
dayatsin-amd wants to merge 9 commits into
Conversation
✅ All Policy Checks Passed
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
cfreeamd
left a comment
There was a problem hiding this comment.
🤖 AI-assisted pre-review (for @cfreeamd)
ROCr files look correct — ELF machine IDs, FAMILY_GFX117X=0x9A, addrlib routing, isa.cpp registrations, blit_kernel, kfdtest.exclude, and rocrtst DEFAULT_TARGETS all follow existing conventions and are internally consistent.
[Required] PR title feat(rocr,hip): uses a non-standard comma-separated scope. Conventional-commit scope should be a single token, e.g. feat(rocr):.
| #ifndef _HIP_INCLUDE_HIP_AMD_DETAIL_HIP_FP8_H_ | ||
| #define _HIP_INCLUDE_HIP_AMD_DETAIL_HIP_FP8_H_ | ||
|
|
||
| #if (defined(__gfx942__) || defined(__gfx1200__) || defined(__gfx1201__) || \ |
There was a problem hiding this comment.
@yxsamliu Could you review from compiler side ?
24ad782 to
195fad2
Compare
I think it is ok to have multiple components in that section. |
Add Medusa1 B0 (gfx1170) and Medusa2 (gfx1171) ISA, ELF, blit, and device tables. PAL Medusa enum uses are guarded so develop still builds without a Medusa PAL. Co-authored-by: jungx098 <jungx098@gmail.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Support was added for Medusa but kfdtest configuration was missed. Co-authored-by: Cursor <cursoragent@cursor.com>
Recognize FAMILY_MDS (gfx1170, gfx1171) and initialize it with the gfx11 address library. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Josic, Slobodan <Slobodan.Josic@amd.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Add the gfx11-7-generic ISA/ELF target and retarget fatbin and comgr fallbacks for gfx1170/gfx1171. Co-authored-by: Cursor <cursoragent@cursor.com>
eb7584e to
9975860
Compare
| {11, 5, 1, "gfx1151", Pal::AsicRevision::StrixHalo}, | ||
| {11, 5, 2, "gfx1152", Pal::AsicRevision::Krackan1}, | ||
| {11, 5, 3, "gfx1153", Pal::AsicRevision::Krackan2}, | ||
| {11, 7, 0, "gfx1170", Pal::AsicRevision::Gfx1170}, |
There was a problem hiding this comment.
Could we keep these entries guarded, or update the PAL headers first? The current Windows build fails because these AsicRevision values are not defined yet.
There was a problem hiding this comment.
After PAL headers are updated, this will be addressed
| {"gfx1171", true, true, 11, 7, 1, NONE, NONE, 2, 32, 1, 256, 64 * Ki, 32, 1024}, | ||
| {"gfx1172", true, true, 11, 7, 2, NONE, NONE, 2, 32, 1, 256, 64 * Ki, 32, 1024}, | ||
| {"gfx11-generic", true, true, 11, 0, 0, NONE, NONE, 2, 32, 1, 256, 64 * Ki, 32, 1024}, | ||
| {"gfx11-7-generic", true, true, 11, 7, 0, NONE, NONE, 2, 32, 1, 256, 64 * Ki, 32, 1024}, |
There was a problem hiding this comment.
Could we check the exact generic target mapping in Isa::isCompatible() instead of comparing ISA versions? Otherwise gfx11-generic is accepted on gfx117x, but LLVM treats gfx11-generic and gfx11-7-generic as separate groups. A negative test would also help.
There was a problem hiding this comment.
See
bool Isa::isCompatible(const Isa& codeObjectIsa, const Isa& agentIsa) {
bool isGeneric = std::strstr(codeObjectIsa.targetId(), "generic") != nullptr;
if (isGeneric) {
if (codeObjectIsa.versionMajor() != agentIsa.versionMajor() ||
codeObjectIsa.versionMinor() > agentIsa.versionMinor() ||
(codeObjectIsa.versionMinor() == agentIsa.versionMinor() &&
codeObjectIsa.versionStepping() > agentIsa.versionStepping())) {
return false;
}
The versionMinor() will prevent gfx117x being accepted as gfx11-generic.
so the original code is right
There was a problem hiding this comment.
LLVM defines gfx11-generic as covering gfx1100–gfx1154, while gfx1170–gfx1172 are covered by gfx11-7-generic. The runtime already records this exact mapping in GenericTargetMapping() and in ROCr’s ISA table.
The current numeric check accepts gfx11-generic on gfx117x because it evaluates 0 > 7 as false. Could we use the exact generic-target mapping here instead and add a negative test for this case?
| {"amdgcn-amd-amdhsa--gfx1151", "amdgcn-amd-amdhsa--gfx11-generic" }, | ||
| {"amdgcn-amd-amdhsa--gfx1152", "amdgcn-amd-amdhsa--gfx11-generic" }, | ||
| {"amdgcn-amd-amdhsa--gfx1153", "amdgcn-amd-amdhsa--gfx11-generic" }, | ||
| {"amdgcn-amd-amdhsa--gfx1170", "amdgcn-amd-amdhsa--gfx11-7-generic" }, |
There was a problem hiding this comment.
Could we share this mapping with GenericTargetMapping()? The two production copies have already drifted for gfx1152 and gfx1153, so keeping one mapping would avoid more inconsistencies.
There was a problem hiding this comment.
This PR focus on target ID support.
But your suggestion is good, could you file a ticket for the task? We can address in another PR.
Rename FAMILY_MDS to FAMILY_GFX1170 (0x9A) to match open-source Mesa addrlib, and enable gfx1170/gfx1171. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
9975860 to
a9d08a2
Compare
|
#11977 - Using this instead of this |
|
🤖 CI Update — Run #35656076730 🆕 New failures (may be related to this PR):
|
Summary
Port gfx1170/gfx1171 (ISA 11.7.x) enablement onto develop for ROCr and CLR: ISA/ELF IDs, blit objects, addrlib gfx117x family, kfdtest filters, OCP FP8,
gfx11-7-genericfatbin/comgr mapping, and PALAsicRevision::Gfx1170/Gfx1171device tables.Co-authored-by: Sang, Tao Tao.Sang@amd.com
Co-authored-by: McRae, Geoffrey Geoffrey.McRae@amd.com
Co-authored-by: Li, Todd tiantuo Toddtiantuo.Li@amd.com
Co-authored-by: Sokolovic, Stefan Stefan.Sokolovic2@amd.com
Co-authored-by: Josic, Slobodan Slobodan.Josic@amd.com
Co-authored-by: jungx098 jungx098@gmail.com
JIRA ID
JIRA ID : AIRUNTIME-2024
JIRA ID : ROCM-29293
Test plan
rocminforeports gfx1170/gfx1171 when presentgfx11-7-genericMade with Cursor