HIP: give top-k a hipCUB path for rows wider than 1024 - #27974
Closed
uncrayon wants to merge 1 commit into
Closed
Conversation
The HIP backend has no CUB, so the shared-memory bitonic argsort is the only top-k path and supports_op caps rows at 1024 elements. Vocabulary-width top-k therefore falls back to the CPU, which copies the whole logits tensor to the host on every call. DFlash2's candidate selector hits this on every draft step: k = 16 over 248,320 logits. Adds a hipCUB DeviceSegmentedRadixSort path for wide rows, behind GGML_HIP_TOPK_HIPCUB (on when hipCUB is found), and lifts the width limit in supports_op for top-k only. ARGSORT keeps its existing limit. test-backend-ops -o TOP_K on gfx1151 goes from 159 OK / 347 unsupported to 441 OK / 0 unsupported / 0 failures, and the DFlash2 draft graph drops from 3 splits to 1. On this host it does not change DFlash2 throughput: 25.52 vs 25.62 tok/s, with byte-identical draft/accept counters. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
github-actions
Bot
added
ggml
|
Hi @uncrayon, thanks for your contribution! Per our contribution guidelines, the automated PR checker found the following issue(s) that need your attention:
Please note that maintainers reserve the right to make final decisions on PRs. If you believe there is a mistake, please comment below. |
ggml-gh-bot
Bot
added
the
draft
github-actions
Bot
removed
the
draft
uncrayon
marked this pull request as ready for review
August 29, 2026 21:14
Contributor
|
dupe of #26592 |
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.
Overview
Hey everyone! This is my first contribution, so please, be as hard as needed for me to learn.
The problem that this PR attack is quite easy to solve but for AMD Users (I run my models in an Evo-X2 128G Ubuntu).
When using DFlash2 for Qwen 3.8 27B Q8 my computer was using the CPU and GPU when using HIP, but not with Vulkan. Looking in my logs I realized that top-k was falling back to the CPU, which copies the whole logits tensor to the host on every call!
Looking in HF I found this blob that took me to learn what hipCUB is and therefore I tried to apply it here. For me was just as simple to do an if.
test-backend-ops -o TOP_K on gfx1151 (the Halo chip) goes from 159 OK / 347 unsupported to 441 OK / 0 unsupported / 0 failures, and the DFlash2 draft graph drops from 3 splits to 1. On this host it does not change DFlash2 throughput: 25.52 vs 25.62 tok/s, with byte-identical draft/accept counters.
Additional information
Requirements
claude/opus-5-ultracodeand code review byopenAI/chatgpt-5.6-sol-ultra.