Fix(sgl-kernel/rocm): enable RDNA3.5 (gfx1151) and cap TopK LDS

[Arkar-Hema]

Motivation

Closes the RDNA gap behind #27519. AMD RDNA3.5 GPUs (gfx1151 — Strix Halo "Ryzen AI MAX") could not build or run sgl-kernel on ROCm, even though the kernels themselves are compatible.

#27535 already improved this by honoring an explicit AMDGPU_TARGET so the build no longer hard aborts at the gfx942/gfx950 whitelist. That is the right first step, but it only opens the gate subtly — it's an opt-in escape hatch ("continue with an unsupported arch") that does not make RDNA actually runnable: the build still emits a TopK kernel sized for CDNA shared memory, which crashes at launch on RDNA. This PR completes the enablement.

What this PR changes

1. sgl-kernel/setup_rocm.py — honor explicit AMDGPU_TARGET + correct the TopK LDS budget

• Keeps the explicit-AMDGPU_TARGET-wins behavior (consistent with / superseding fix(sgl-kernel/rocm): honor explicit AMDGPU_TARGET over auto-detection #27535) so RDNA targets build without removing the upstream whitelist guard.
• Fixes the dynamic-shared-memory budget for the TopK kernels. Previously:

  topk_dynamic_smem_bytes = 48 * 1024 if amdgpu_target == "gfx942" else 32 * 1024 * 4  # 128KB for everything else

  The 128KB branch only fits CDNA3 (gfx950/MI350, ~160KB LDS). gfx942 and RDNA3.5 have only 64KB LDS per workgroup, so 128KB is rejected at kernel launch. Changed to whitelist the large-LDS arch instead of assuming "not gfx942 ⇒ large":

  large_lds_targets = ["gfx950"]
  topk_dynamic_smem_bytes = 32 * 1024 * 4 if amdgpu_target in large_lds_targets else 48 * 1024

  Behavior-preserving for gfx942 (48KB) and gfx950 (128KB); RDNA and any unknown future arch default to the safe 48KB.

2. python/sglang/srt/utils/common.py — robust AMD memory detection

• get_amdgpu_memory_capacity() shells out to rocminfo; on some ROCm stacks (observed with TheRock on Strix Halo) rocminfo returns no parseable pool size or segfaults, which raised and prevented server startup. Added a fallback to torch's mem_get_info() (the helper already used elsewhere in this file) when rocminfo yields nothing.

Why #27535 alone is not enough (the subtle part)

With only #27535, AMDGPU_TARGET=gfx1151 python setup_rocm.py builds and the wheel imports — so it looks supported — but the first call into the TopK kernel fails:

RuntimeError: set_up_kernel_once failed: invalid argument

This is hipFuncSetAttribute(hipFuncAttributeMaxDynamicSharedMemorySize, 131072) being rejected because 128KB > the 64KB LDS limit on RDNA. Normal dense / standard-MoE serving never reaches this kernel, so a smoke test passes and the regression stays hidden; it only surfaces on the DeepSeek-V3.2 sparse-attention TopK path (fast_topk_v2, topk=2048) and deepseek_v4_topk.

Testing

Hardware: AMD Ryzen AI MAX+ 395 / Radeon 8060S (gfx1151, RDNA3.5), PyTorch 2.10+rocm7.13.
Device LDS confirmed: torch.cuda.get_device_properties(0).shared_memory_per_block == 65536 (64KB).

Validated three configurations on the same hardware:

Config	Build (AMDGPU_TARGET=gfx1151)	SGL_TOPK_DYNAMIC_SMEM_BYTES	TopK kernel (fast_topk_v2, topk=2048)
Upstream (pristine)	aborts at gfx942/950 gate	—	—
#27535 only	builds, wheel loads	131072 (128KB)	CRASH — set_up_kernel_once failed: invalid argument
This PR	builds, wheel loads	49152 (48KB)	OK — returns valid indices

• Build: all 16 HIP translation units compile cleanly for gfx1151; wheel imports and loads on the GPU.
• TopK kernel: reproduced the crash deterministically by calling the exact op the DeepSeek sparse-attention path uses (from sgl_kernel import fast_topk_v2; fast_topk_v2(score, lengths, 2048)); with this PR's 48KB cap the identical call succeeds.
• End-to-end serving: sglang.launch_server with Qwen/Qwen2.5-0.5B-Instruct (triton attention backend) starts and serves correct /v1/chat/completions responses on gfx1151.
• No CDNA regression: gfx942 stays at 48KB and gfx950 stays at 128KB (logic is behavior-preserving for both).

---

CI States

Latest PR Test (Base): ❌ Run #27680257272
Latest PR Test (Extra): ❌ Run #27680257105

[gemini-code-assist]

Code Review

This pull request improves ROCm support by handling rocminfo failures gracefully via a PyTorch fallback, allowing explicit AMDGPU_TARGET overrides during compilation on hosts with active GPUs, and capping dynamic shared memory for gfx1151. The review feedback suggests wrapping the rocminfo parsing in a try-except block to prevent unhandled ValueError exceptions, and whitelisting only large LDS targets (like gfx950) to default all other architectures to the safe 48KB limit and avoid runtime crashes.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.