Improve int4 AWQ GEMV performance on Radeon 8060S and similar GPUs

[eble-amd]

Purpose

Improve GEMV performance on Radeon 8060S and similar GPUs.

Test Plan

• vllm benchmark with Gemma 2B AWQ
• pytest performance tests (new golden values included)

Test Results

Copied from commit message:

Measured on Radeon 8060S (gfx1151, 2 MiB L2):
- 1x2048x16384: 141 -> 149 GiB/s (+5%)
- 1x2560x2048:  162 -> 166 GiB/s (+2%)
- 1x32768x2048: 199 -> 200 GiB/s (+1%)
- Overall for Gemma-2B AWQ int4: 67.5% -> 69.3% roofline

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[mgehre-amd]

d6fd7b6 had tuned the non-quantized version of the skinny GEMM for K=2048 by increasing the AC template argument from 8 to 16. Would the same help here?

[mgehre-amd]

The effect of the delay might be the same as the effect of staggering the start addresses of each block

[eble-amd]

d6fd7b6 had tuned the non-quantized version of the skinny GEMM for K=2048 by increasing the AC template argument from 8 to 16. Would the same help here?

Unless I'm looking at the wrong thing, this MR bumps it from 16 to 32.

[eble-amd]

The effect of the delay might be the same as the effect of staggering the start addresses of each block

Since we discussed (elsewhere) spending time to dig deeper into why the staggering is helping, I removed the staggering commit from this PR so that it doesn't delay merging the other improvement.