#2305 HIP (R9700, gfx1201): the MTP draft is fast or slow depending on the engine start; `GPU_MAX_HW_QUEUES=2` makes every start the fast one

本文

**What we see.** With `STRATA_DECODE_TIMING=1` (server, UD-IQ4_XS, every expert in RAM, `--spec 4 --spec-min-p 0.5 --mtp`,
`STRATA_HIP_WMMA=1 STRATA_ROUTE_RESIDENT=1`, greedy, 512-token answers) the `draft` part of a window is one of two values,
fixed for the life of an engine and different from one start to the next with the same binary, flags and requests:

| card | draft, fast starts | draft, slow starts | how often slow (default queues) |
|---|---|---|---|
| R9700, PCIe 4.0 x16 | 2.3-2.9 ms/window | 3.8-4.4 ms/window | 2 of 6 starts |
| R9700, PCIe 3.0 x4 (chipset) | 2.9-5.1 ms/window | 8-13 ms/window | 1 of 6 starts here; both starts of an earlier batch |

The verify part does not change (24-26 ms/window on x16, 27-29 on x4), so a slow start costs ~6% of decode on x16 and up
to ~25% on x4.

**What changes it.** `GPU_MAX_HW_QUEUES` (HIP's limit on hardware queues per process, default 4), same binary, 2-3 requests
per start, alternating:

| GPU_MAX_HW_QUEUES | x16 draft | x4 draft |
|---|---|---|
| 1 | 2.8-3.2 (2 starts) | 6.3-9.3 (2 starts) |
| **2** | **2.2-2.8 (6 starts, all)** | **2.8-4.2 (6 starts, all)** |
| 4 (default) | bimodal, above | bimodal, above |
| 16 | 4.3-4.6 (2 starts, both slow) | 2.7-9.4 (2 starts) |

Our reading, not proven from the runtime's side: HIP maps the process's streams onto its hardware queues round-robin
in creation order. When the drafter's `cs_` shares a hardware queue with the verify window's stream, the hand-offs
between them stay in one queue; when it lands on another one, every hand-off crosses queues and costs more - more so
through a chipset link. With 16 queues every stream has its own (always slow); with 1 the drafter also waits behind the
adaptive tier's copies (slow on x4); with 2 the drafter and the verify window always share one. #1240 (a side stream that
cost an R9700 prompt speed) looks like the same family; #2245 is about hangs on gfx103x, not this.

**Workaround** that works here: `GPU_MAX_HW_QUEUES=2` in the run config's `env`. A fix in the engine would not depend on
the runtime's mapping, for example drafting on the verify window's stream on HIP, or creating the streams in an order
that puts the two together. Happy to test a change on both cards.

**Not tested:** other RDNA4 / RDNA3 cards, NVIDIA (no hardware-queue mapping of this kind), sampled requests over many
starts (under temperature 1.0 the draft part is smaller and the difference less visible), layer splits.

**Related, same setup (separate finding).** `arch_defaults.cpp` keeps the decode half of the gfx1151 table off on gfx12
("measured slower on that card", #1478). With every expert in RAM, `STRATA_ROUTE_RESIDENT=1` and two hardware queues,
the exact ones together - `STRATA_LFUSE EXPERT_V2 TSUM MMVF_ROWS QFUSE GDN_SPLIT ATTN_LANECELL PLE_BATCH` - were faster
on the R9700 x16: verify 25.8 -> 24.8 ms/window, the whole window -3.7%, two starts per arm interleaved, 12 of 12
answers byte-identical. One at a time each moved less than the run-to-run spread. `STRATA_Q8_PACKED` / `Q6_PACKED`
changed the output here, so they are left out. Not measured: the budget (complement) mode #1478 may have used.