[ROCm] warpSize is being made non constexpr in ROCm 7.0 #20330
Conversation
Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com>
|
👋 Hi! Thank you for contributing to the vLLM project. 💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels. Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging. To run CI, PR reviewers can either: Add 🚀 |
There was a problem hiding this comment.
Summary of Changes
Hello @gshtras, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request implements a necessary adaptation for compatibility with the upcoming ROCm 7.0 release. It modifies how the WARP_SIZE constant is determined within the codebase, moving away from a runtime-dependent variable to a compile-time macro that intelligently selects the correct warp size based on the target GPU architecture. This change ensures the stability and correct compilation of kernels under the new ROCm environment.
Highlights
- ROCm 7.0 Compatibility: This pull request addresses a critical breaking change introduced in ROCm 7.0, where the
warpSizevariable is no longer aconstexpr. This change prevents its direct use in compile-time contexts, which previously relied on its constant nature. - Updated
WARP_SIZEDefinition: To maintain compile-time constant behavior, theWARP_SIZEmacro's definition has been updated. It now explicitly setsWARP_SIZEto 64 when compiling for ROCm on GFX9 architectures (e.g., AMD Instinct MI100/MI250) and to 32 for all other platforms, including NVIDIA CUDA and other ROCm targets. - Consistent Macro Application: The revised
WARP_SIZEdefinition has been applied consistently across multiple core files:csrc/attention/attention_kernels.cuh,csrc/attention/paged_attention_v1.cu,csrc/attention/paged_attention_v2.cu, andcsrc/cuda_compat.h. This ensures uniform behavior and compatibility across the codebase.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com>
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request addresses a breaking change in ROCm 7.0 where warpSize is no longer a constexpr. The approach is to centralize the WARP_SIZE definition in csrc/cuda_compat.h and use preprocessor directives to set a compile-time constant.
The refactoring to a central header is a good improvement. However, the implementation for determining WARP_SIZE on ROCm is not fully correct. It handles GFX9 GPUs but makes a potentially incorrect assumption for newer GFX10+ architectures, which can lead to bugs if the code is compiled with a 64-wide wavefront. I've provided a critical review comment with a suggested fix that aligns with AMD's recommendation to use the __AMDGPU_WAVEFRONT_SIZE__ macro for a more robust solution.
| #ifndef USE_ROCM | ||
| #define WARP_SIZE 32 | ||
| #if defined(USE_ROCM) && defined(__GFX9__) | ||
| #define WARP_SIZE 64 |
There was a problem hiding this comment.
Is warpSize from the previous implementation 64?
…#20330) Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com> Signed-off-by: Himanshu Jaju <hj@mistral.ai>
…#20330) Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com>
Commits included: Using cuda_compat to defint the WARP_SIZE once Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com> On ROCm toe constant compile time warp size can not be used on the host side that can be shared for multiple architectures with different values Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com> Formatting Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com> Refactor to use cuda_compat, and not the unhippified version Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com> Leaving CUDA side as just a simple define Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com>
Commits included: Using cuda_compat to defint the WARP_SIZE once On ROCm toe constant compile time warp size can not be used on the host side that can be shared for multiple architectures with different values Formatting Refactor to use cuda_compat, and not the unhippified version Leaving CUDA side as just a simple define Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com>
…#20330) Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com> Signed-off-by: avigny <47987522+avigny@users.noreply.github.com>
…#20330) Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com> Signed-off-by: x22x22 <wadeking@qq.com>
…#20330) Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com>
…#20330) Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com>
…#20330) Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com> Signed-off-by: Jinzhen Lin <linjinzhen@hotmail.com>
…#20330) Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com> Signed-off-by: Paul Pak <paulpak58@gmail.com>
…#20330) Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com>
…#20330) Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com> Signed-off-by: Diego-Castan <diego.castan@ibm.com>
…#20330) Signed-off-by: Gregory Shtrasberg <Gregory.Shtrasberg@amd.com>
ROCm7.0 hip compiler adds a breaking change of making warpSize a non constexpr value
Using an alternative method of deducing the right warp size to use
References:
https://rocm.blogs.amd.com/ecosystems-and-partners/transition-to-hip-7.0:-guidance-on-upcoming-compatibility-changes/README.html#warpsize-change
https://rocm.docs.amd.com/en/latest/about/release-notes.html#amdgpu-wavefront-size-compiler-macro-deprecation