CUDA: enable the CUB path on HIP via hipCUB - #26592
Conversation
The CUB-based ARGSORT/TOP_K (and sum/mean/cumsum) paths were compiled out for HIP, so those ops fell back to the shared-memory bitonic sort. That sort uses one thread per element, so it is limited to rows of 1024 elements; anything wider was reported as unsupported and ran on the CPU. For deepseek4 that meant every lightning-indexer TOP_K above 1024 context went to the host, adding a graph split per layer. hipCUB provides the device-wide sorts these paths need - the rocPRIM backend has DeviceRadixSort, DeviceSegmentedRadixSort, DeviceSegmentedSort, DeviceReduce and DeviceScan - so include it through a small cub-compat shim that aliases the cub namespace, and define GGML_CUDA_USE_CUB for HIP as well. hipCUB has no DeviceTopK and does not define CCCL_*, so CUB_TOP_K_AVAILABLE and STRIDED_ITERATOR_AVAILABLE stay disabled there: TOP_K keeps using the argsort + copy path and argsort keeps using the init_offsets kernel instead of a strided iterator. vendors/hip.h gains the stream-capture defines that the CUB argsort path needs now that it is compiled for HIP.
|
@ggml-org/ci Looks like CI hip workflows need to be updated to install hipcub dev package for this. Not sure about HIP Windows release, but I guess that's something to worry about later. |
|
So test this PR here with 4x gfx1200 9060xt and 1x gfx1151. No crash at 68727 PP context. |
|
@fairydreaming isn't hipcub included in rocm? |
@Geramy No idea, my adventure with AMD GPUs ended during Radeon R9 290 times. By the way, could you run some Thanks! |
|
@fairydreaming from AMD GitHub page directly |
|
Cline is working now including reasoning and cache with up to 172k tokens for me over rpc. Edit: by 193k tokens ca. 600mb VRAM increase per GPU i can observe. |
Well for some reason hipCUB header files were missing in the CI container during compilation, I see that it installs Ubuntu rocblas-dev and hipblas-dev packages, so maybe they also need to install libhipcub-dev or something. |
Yeah perhaps it depends on the ROCm version we are on too. Who will or can take care of that? |
@Geramy I don't know, if no one fixes it I'll see what I can do tomorrow (going to sleep soon). |
|
Confirmed to work on a Strix Halo: with this patch the tg speed stays correct even after >4-5k context (instead of having a big drop to 5 tok/s). 🎉 However, I'm wondering if the prefill speed doesn't get worse faster than with #26493, but that can be totally wrong, don't read too much into this. |
Overview
Since the CUB-based ARGSORT/TOP_K paths were never running on a HIP based device, I have enabled them and added a few missing hip graph functions. Originally those ops fell back to the shared-memory bitonic sort. That sort uses one thread per element, so it is limited to rows of 1024 elements; anything wider was reported as unsupported and ran on the CPU.
Additional information
I have added stream-capture functions missing from vendors/hip.h which is required in CUB argsort.
DeepSeek-V4-Flash UD-IQ1_S — 284B MoE, 78 GB
pp512prompt processing
tg32token generation
Qwen3.6-35B-A3B UD-Q4_K_XL
pp512prompt processing
tg32token generation
Requirements
@IMbackK @am17an @pwilkin