ROCm backend on discrete gfx1100 (RX 7900 XTX) — has anyone tried it?

Hi, first off — great project, the asymmetric quantization approach for V4 Flash is really clever.

I'm looking into running the ROCm backend on a discrete AMD GPU (Radeon RX 7900 XTX, gfx1100 / RDNA3) instead of a Strix Halo APU (gfx1151 / RDNA3.5). Before spending time on it I wanted to check whether anyone has already tried this, since all the ROCm documentation and code I could find (STRIXHALO.md, the `rocm_tier_valid` single-GPU check, `ds4_gpu_args_probe_auto_cuda`) seems to target Strix Halo specifically.

**Full disclosure up front: I'm an engineer with a strong background in math and a real passion for programming, but not a professional software developer. I've been using AI assistance (Claude) to help me read through the codebase and put this analysis together, and I'll be using AI assistance for the implementation work too if this turns out to be feasible. I'm saying this openly because I want any feedback to account for that — I'm approaching this as a serious, hands-on hobbyist project, not pretending to have more systems/GPU programming experience than I do.**

A few things I've dug into on my own, posting in case they're useful context:

1. **Compute kernels**: `ds4_rocm.cu` uses `__dp4a` via the `amd_mixed_dot` builtin, which maps to `v_dot4_i32_i8` on "gfx11-class" AMD GPUs generally, not something gfx1151-specific as far as I can tell. From what I could find on RDNA3 vs RDNA3.5 ISA differences, the two share the same core dot-product/matrix instruction set the notable differences (scalar FP ops, VGPR file size, texture/interpolation rates) don't seem to touch the kernels this project uses. gfx1100 actually has the same large 192KB VGPR file as gfx1151, unlike the smaller gfx1150.

2. **Memory model**: this looks like the real difference. Strix Halo is unified memory (GPUVM/GTT mapping system RAM as GPU-visible), which is why STRIXHALO.md needs the `amdgpu.gttsize` kernel param trick. A discrete GPU has real dedicated VRAM instead. Looking at `ds4_rocm_compat.cu`, `ds4_gpu_tensor_alloc_on` for ROCm is a direct `hipMalloc` with no offload/spill path which would be fine for whatever fits in 24GB, but there's no RAM/SSD spillover mechanism for ROCm the way Strix Halo has via GTT, or CUDA has via managed memory. Is that assessment right, or is there something I'm missing?

3. **Single GPU limitation**: `rocm_tier_valid()` and the `ds4_gpu_args_probe_auto_cuda` error message ("ROCm supports one GPU per process") both hardcode single-GPU. That's fine for my use case (I'd run two separate `ds4` processes (one CUDA, one ROCm) using `--role coordinator`/`--role worker` and `ds4_distributed.c` over localhost TCP to combine VRAM across an NVIDIA card and the XTX). Just flagging in case that's a relevant detail for anyone else with mixed-vendor setups.

**Questions:**
- Has anyone actually run `make strix-halo` with `ROCM_ARCH=gfx1100` (or similar) on a discrete RDNA3 card? Any reports, even partial/broken ones, would save me some time.
- Is the memory-model gap (no offload path for ROCm on cards where the full model doesn't fit in VRAM) accurate, or is there something in the pipeline I haven't found?
- Any known gfx1100-specific issues with rocWMMA or the attention/MoE kernels that wouldn't show up on gfx1151?

Happy to test on my end (RX 7900 XTX 24GB + RTX 4080 Super 16GB, Ubuntu) and report back either way — I can test the ROCm backend standalone on the XTX, the CUDA backend standalone on the 4080S, and eventually the two-process distributed setup across both.