rocm: implement the two DSpark kernels so --dspark can draft on gfx1151 (fixes #597)

[zom-2018]

Summary

Fixes #597 — "DSpark never produces a draft on ROCm / gfx1151".

Root cause: the DSpark engine path in ds4.c is backend-shared, but two GPU
kernels it needs existed only in ds4_cuda.cu. ROCm builds resolved them
through ROCM_UNAVAILABLE_INT stubs in ds4_rocm_unavailable.cu, so the
session probe always failed and every propose cycle ended with proposed=0.

This PR implements both kernels for ROCm (HIP) and removes the two stubs:

• dspark_markov_argmax_kernel + ds4_gpu_dspark_markov_argmax_tensor
  (rocm/ds4_rocm_indexer.cuh): on-device markov-chain argmax over the vocab
  with q8_0 w1/w2 rows — direct port of the CUDA kernel, same monotonic-key
  atomicMax tie-break.
• attention_noncausal_raw_batch_heads_kernel +
  ds4_gpu_attention_noncausal_raw_batch_heads_tensor
  (rocm/ds4_rocm_attention_launch.cuh): non-causal batch attention over the
  raw KV ring for draft blocks — direct port, same one-block
  max/denominator/value accumulation order; keeps the
  DS4_DSPARK_VERIFY_NONCAUSAL host-side oracle for the first 3 launches.

Signatures match the existing declarations in ds4_gpu.h; no other files are
touched.

Scope / safety

• ROCm-only change. No effect on CUDA, Metal, or CPU builds.
• No behavior change unless --dspark is used (the kernels are only reached
  through the DSpark propose/verify path).

Measured on AMD Strix Halo (Ryzen AI Max+ 395, Radeon 8060S gfx1151), ROCm 7.2

Before (upstream): proposed=0 every cycle (exactly the #597 symptom).

After, --dspark-confidence 0.3, 300 generated tokens, DeepSeek-V4-Flash-0731
abliterated GGUF (80.76 GiB) + its DSpark support drafter:

cycles=89 proposed=216 accepted_draft=206 accept_rate=95.37% avg_accept=2.315
full=39 partial=5 draft_len_hist=1:8,2:5,3:1 accepted_len_hist=0:118,1:10,2:3,3:1

At the default --dspark-confidence 0.9 the adaptive scheduler stays
conservative: proposed=21, accept_rate=90.5%.

Wall-clock is currently break-even on this bandwidth-bound APU (the 6-row
target verify costs ~4–5x a single decode pass, dominated by routed-expert
weight reads), so this is not a speedup claim — it makes DSpark functional
on ROCm, which is the precondition for any follow-up verify-path optimization.

Testing

• make strix-halo clean (gfx1151).
• CLI generation with --dspark + DS4_DSPARK_STATS=1: drafts proposed,
  verified and accepted; coherent output; stats counters advance.
• Without --dspark: unchanged behavior.

---

Update: DSpark kernel speedups (this branch now also makes it fast)

The port above drafted correctly but slowly. A follow-up commit on this branch
optimizes the draft + verify kernels; on the same Strix Halo box that moves the
speculative path from ~0.67x to ~0.81x of plain decode
(dspark_tps 10.71 -> 13.05, verify 135 -> 100 ms/cycle), still lossless.

Markov draft kernel:

• 4096x32 one-row-per-thread grid (was 128x256); vals/idxs 768.
• Aligned uint16 pair loads in the w2 dot loop and the w1 state init.
• Alternate the w2 scan direction per chain step (L3 tail reuse; argmax is
  direction-independent, so oracle-safe).

Verify path:

• Batched parallel argmax for top_k=1 row tops (argmax_rows_kernel),
  replacing a single-threaded ~13 ms insertion-sort kernel.
• Adaptive token tile (8/16/32 by n_tok) for the shared-x batch q8 matmuls
  (a fixed 32-wide tile wasted up to 6x ALU at the small verify batch;
  per-token accumulation order unchanged, bit-identical).
• float4 output accumulation in the non-causal draft-block attention.
• MoE float-down rows_per_block 16 -> 32.

The speedups touch only ROCm kernel files plus the ds4.c / ds4_gpu.h /
ds4_cuda.cu reverse-scan plumbing; outputs remain byte-identical to plain
greedy decode (accept oracle passes).

[zom-2018]

Update: refreshed the description and pushed a follow-up commit (88825d3) that
makes the DSpark path fast, not just functional.

rocm: speed up the DSpark draft + verify kernels on gfx1151 — 7 files, +132/-21:

Markov draft kernel (rocm/ds4_rocm_indexer.cuh)

• 4096x32 one-row-per-thread grid (was 128x256), vals/idxs 768
• aligned uint16 pair loads in the w2 dot loop + w1 state init
• alternate the w2 scan direction per chain step (L3 tail reuse, oracle-safe)

Verify path

• batched parallel argmax for top_k=1 row tops (was a single-threaded ~13 ms kernel)
• adaptive token tile (8/16/32 by n_tok) for the shared-x batch q8 matmuls
• float4 output accumulation in the non-causal draft attention
• MoE float-down rows_per_block 16 -> 32

Measured on Strix Halo (gfx1151), still lossless / byte-identical to greedy decode:
dspark_tps 10.71 -> 13.05 (~0.67x -> ~0.81x of plain decode), verify 135 -> 100 ms/cycle.