Repository navigation
Revert correcting the VGPR size for GFX 11.5.1 - #2268
Conversation
There was a problem hiding this comment.
Pull request overview
This PR reverts a previous correction to the VGPR size for GFX 11.5.1 to address kernel/userspace compatibility issues. While the previously corrected value (0x60000) was technically correct, it causes problems with kernels prior to 6.17.9 and 6.18 that have strict restrictions. The revert allows GFX 11.5.1 to fall back to the default VGPR size (0x40000) temporarily, until newer kernels can communicate the correct size directly.
- Removes GFX_VERSION_GFX1151 from the condition that sets VGPR size to 0x60000, allowing it to use the default 0x40000 instead
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
You can explicitly delete the patch from TheRock in these workflows, by adding a new line with the specific file name. https://github.com/superm1/rocm-systems/blob/revert-vgpr-strix-halo/.github/workflows/therock-ci-linux.yml#L68 |
By including the changes to these workflows in this same PR, the chicken-egg problem is dealt with. |
06940ae to
77497f7
Compare
github-actions
Bot
added
the
github actions
Although the value is correct; there is no source of truth between kernel and userspace. This leads to problems if the kernel has strict restrictions (such as kernel 6.17 or earlier). The restrictions were lifted in 6.17.9 and and 6.18, but there is no guarantee userspace is using this. So short term this value will be wrong. But on newer kernels the kernel will communicate the right size and rocr-runtime will be adjusted to use that. Link: ROCm/TheRock#2505 Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
77497f7 to
dd3f03f
Compare
Although the value is correct; there is no source of truth between kernel and userspace. This leads to problems if the kernel has strict restrictions (such as kernel 6.17 or earlier). The restrictions were lifted in 6.17.9 and and 6.18, but there is no guarantee userspace is using this. So short term this value will be wrong. But on newer kernels the kernel will communicate the right size and rocr-runtime will be adjusted to use that. Link: ROCm/TheRock#2505 Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> [rocm-systems] ROCm/rocm-systems#2268 (commit 0c4d08f)
Although the value is correct; there is no source of truth between kernel and userspace. This leads to problems if the kernel has strict restrictions (such as kernel 6.17 or earlier). The restrictions were lifted in 6.17.9 and and 6.18, but there is no guarantee userspace is using this. So short term this value will be wrong. But on newer kernels the kernel will communicate the right size and rocr-runtime will be adjusted to use that. Link: ROCm/TheRock#2505 Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
- Bump `rocm-systems` 20251218 - Drop `0002-Revert-hsakmt-bump-vgpr-count-for-gfx1151-1807.patch` mapped to ROCm/rocm-systems#2268 - Addresses #2642 thanks to ROCm/rocm-systems#2399
- Bump `rocm-systems` 20251218 - Drop `0002-Revert-hsakmt-bump-vgpr-count-for-gfx1151-1807.patch` mapped to ROCm/rocm-systems#2268 - Addresses ROCm#2642 thanks to ROCm/rocm-systems#2399
Although the value is correct; there is no source of truth between kernel and userspace. This leads to problems if the kernel has strict restrictions (such as kernel 6.17 or earlier). The restrictions were lifted in 6.17.9 and and 6.18, but there is no guarantee userspace is using this.
So short term this value will be wrong. But on newer kernels the kernel will communicate the right size and rocr-runtime will be adjusted to use that.
Link: ROCm/TheRock#2505