[ROCm] Restore Wave64 warp size for all gfx9 targets - #2059
Open
0xDELUXA wants to merge 1 commit into
Open
Conversation
0xDELUXA
changed the title
Contributor
|
LGTM, cc @matthewdouglas |
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.
PR #2012 narrowed the HIP warp size condition in
csrc/common.cuhfromdefined(__GFX9__)toIS_CDNA, which matches only gfx908, gfx90a, gfx942 and gfx950. The pre-CDNA gfx9 parts (gfx900 through gfx90c) and the gfx940/gfx941 CDNA3 revisions are Wave64 as well, and now resolveBNB_WARP_SIZEto 32.That value gates the block primitive choice in
kQuantizeBlockwise. With a 32-thread block and a warp size reported as 32, the guard incsrc/kernels.cuselectsBLOCK_LOAD_WARP_TRANSPOSE, and rocPRIM rejects it throughBlockSize % wavefront::min_size() == 0because the hardware wavefront is 64. Building withBNB_ROCM_ARCH=gfx900orgfx906therefore fails on ROCm 7.16 with that static assert in every blocksize-64kQuantizeBlockwiseinstantiation. Restoring the__GFX9__test fixes both the build and the reported warp size.IS_CDNAstays as it is, so the 4-bit GEMM math path dispatch is unchanged, andgemm_4bit_simt.cuis unaffected either way since it uses fixed 32-lane subgroups rather thanBNB_WARP_SIZE.Verified on ROCm 7.16 by compiling
csrc/kernels.cu,csrc/ops.cu,csrc/gemm_4bit.cuandcsrc/gemm_4bit_simt.cufor gfx900, gfx906, gfx90a, gfx1030, gfx1100, gfx1200 and gfx1250: gfx900 and gfx906 fail before the change, every target compiles after it. A full Windows wheel spanning 27 targets including gfx900 and gfx906 builds and packages cleanly: https://github.com/0xDELUXA/bitsandbytes_win_rocm/releases/tag/0.50.2.dev0-py3.12-rocm7.16-win_amd64_all.cc @sstamenk