HIP: RDNA 4 MUL_MAT optimizations - #25940
Conversation
|
llama-bench table seems to have reversed column values? master is faster than PR on pp, but shown as positive delta. |
|
Yesterday I pulled this PR, compiled new binaries and ran some tests. They showed a good speedup since yesterday. I have been using llama-server as I usually do with 0 issues. In short: Thanks for the fix! It had an immediate ~37% PP speedup on my setup! The longer version:I did some testing to make sure the PR worked with the models and quants that I use daily and here are the results:(GLM 5.2 generated but humanly checked for validity) Hardware
Builds (identical cmake flags, both built with GCC 13.3.0)
KV cache quants tested: f16 (default), q8_0/q8_0, q5_1/q5_1, q4_0/q4_0, q8_0/q4_0 (mixed key/value). Results below are f16; KV cache quant had <1% effect on the PR's delta in all configs. Methodology: Warmup pass (pp4096 -n 1 -r 1, discarded) + 8 repetitions. Same model order, same GPU, single sequential script. Both binaries benchmarked with identical methodology. Results — prompt processing (t/s)
Results — token generation (tg128, t/s)
Summary: Q6_K models see +28-37% prompt processing gains across all batch sizes. Q4_K_M sees +4%. IQ4_XS unchanged. Token generation flat (±0.5%). Gains are KV-cache-independent (tested q8_0, q5_1, q4_0, mixed — all within ±1% of f16 delta). No regressions |
|
I briefly tested this with llama-bench on a IQ3 quant of Qwen3.6 (my previous install was commit Great fix, I hope this can get merged soon!In particular |
|
Im just curious why did you decide to specify unroll prior to the for loop? Did this directly effect performance? Does this have implications for other rocm architectures? |
|
@Geramy From what I've found, rocm's llvm would try to unroll the loop and end up not being able to reuse the registers in the loop. Disabling unrolling allows it to reuse the registers, so it doesn't spill into the scratch memory. I've tested this on rdna 3 as well and I remember there wasn't a regression, but I can try it again to be sure. I can't test this on cdna as I don't have any. |
Oh that’s okay, I mostly was curious what the deeper intention was and that’s pretty cool you have been able to isolate this. |
|
Please use real models rather than export mn=llama_3-8b
for q in q4_0 q4_1 q5_0 q5_1 q8_0 q2_k q3_k_s q4_k_s q5_k_s q6_k iq1_s iq2_xxs iq2_xs iq2_s iq3_xxs iq3_xs iq3_s iq3_m iq4_nl iq4_xs; do echo $q; ./bench --model models/opt/${mn}-${q}.gguf -r 1 -fa 1 -n 0 -p 2048 -ub "16-2048*2" -o sql|sqlite3 llama-bench.sqlite; sleep 10; doneYou can then use |
|
@JohannesGaessler Could you point me to the model on huggingface? Or did you mean I should quant this locally? Afaik, some quant providers will mix different types of quants in different layers to get a better perplexity or kld, so comparison will be inconsistent. In terms of splitting the PR, should I make 3 separate PRs? Then for the hardware, I don't have any cdna gpus, I only have rdna 3 and 4. I know the Q6 and Q2 changes will affect cdna build, but I can't test these. |
|
Just use any small model and produce the quants yourself, something like 8b is already enough. I use LLaMA for consistency across time but it doesn't really matter. I can provide test converage for CDNA. But importantly: I only recently refactored the MMQ code and the values in |
c38ecc9 to
ae6e2bd
Compare
|
@JohannesGaessler rebased on 298219f and ran the benchmarks. I'll only put some of the ones that have a difference bigger than 5% since the table is fairly big. I'm uploading the tables as I got them from I couldn't get some of the IQ quants, since I don't have an imatrix. If you want me to also get those, I'll look into it. Regarding RDNA 3 (7900 XTX)
RDNA 4 (9070 XT)
|
|
If either of you want I could start doing some optimizations for 3.5 the reason I hopped onto this PR is because I was looking for llama work to do and so I would like to create a MMQ dispatch config for RDNA3 and 3.5 specifically since they don’t share the same architecture as RDNA2 or 4 and they don’t have their own configuration. @JohannesGaessler @itterative |
|
Sorry, my previous post had a typo. It should have read: "Before a PR that makes changes to the base code that affects all quantization types and GPUs I want you to make a PR that tunes those values." I don't have the capacity right now to tune those values myself.
Use HTML tags like |
|
I'll give it a try. For now, I'll change the pr to a draft. |
|
@JohannesGaessler I have made a tune PR for 3.5 and 4, also added 3 but I do not have 3 hardware, if @itterative you want to run a test I would be grateful and if you want to suggest changes to the tuning do so. |
|
I've done a script last night to tune the mmq table on both rdna 3 and 4. It finished this morming; will compare results later on today. |
Awesome, I look forward to it it’s I’m GMT -08 so I’ll catch it on my next cycle haha. |
|
@Geramy Some have a speedup, some have some regression. Now, since you made a pr, not sure where I should put mine. I'll probably wait until yours gets merged. RDNA 4 mmq (not including fixes from this pr)
|
|
@itterative i could give you or access to my repo if you like and you can merge our tunes, best tune stays. :) |
|
Pushed the tunes for RDNA 3 & 4 from my side in #26284 |
This comment was marked as spam.
This comment was marked as spam.
|
is this still relevant vs master? if not please close it |
|
@IMbackK the fixes in |
|
@IMbackK I've ran the llama 8b on rdna 4 and it does seems like it's still worth adding this in. I haven't tried to sweep I'll run rdna 3 an report if there's any changes on that. RDNA 4 master vs PR
RDNA 4 master vs 140878b (original mmq conditions)
RDNA 4 140878b (original mmq conditions) vs PR
|
|
I ran the same benchmark on rdna 3 as well. These are all using RDNA 3 master vs PR
|
ae6e2bd to
2ba97e5
Compare
gfx1200 coverage data for the RDNA4 matmul work
Environment
Coverage for the n=512 regressions
q2_K and q6_K at n=512 are off a cliff vs the field on gfx1200 - consistent with Model-level anchors (same card, factory files)
* pp512 +/- is cold-first-rep clock warmup, stable across decode reps. Notes for reviewers
|
Overview
RDNA4 fixes for Q6_K and Q2_K and updates for mmq conditions.
Additional information
Checked with
test-backend-ops test -o MUL_MATandtest-backend-ops grad -o MUL_MAT -p "type_a=(q2_K|q4_0|q4_1|q4_K|q5_0|q5_1|q5_K|q6_K)". Compiled using ROCM 7.15 (TheRock 20260717)For both Q6_K and Q2_K, it seems like rocm llvm doesn't handle current code appropriately (Q6_K doesn't do float conversion before int multiplication and Q2_K loop unrolls and spill into scratch).
For the quants sweep, tried to sweep both n (ne11) and n_experts.
test-backend-ops perf -o MUL_MAT
llama-bench -m Qwen3.5-9B-Q4_K_M.gguf -p 512,2048,4096 -n 128 -r 3
Requirements