AMD ROCm in WSL Containers via /dev/dxg, without /dev/kfd (Strix Halo)

ACE K2 is designed around a simple separation of authority: the model doing the work is not the authority that decides whether the work passes. The local foreman can investigate a goal, select tools, recover from bounded failures and escalate when necessary, but independent controls qualify capabilities and evaluate results.

A human supplies the engineering objective and success boundary.

The local model researches, plans and proposes actions.

Qualified capabilities perform bounded work and preserve evidence.

Independent controls decide pass, recovery, escalation or terminal outcome.

ACE K2 independently validated AMD ROCm GPU access for Windows Subsystem for Linux containers on physical Strix Halo gfx1151 hardware. In controlled A/B testing with matched WSL-aware ROCm userspace, GPU projection using --gpus all produced successful HIP execution in 3/3 runs, while the corresponding no-projection control failed HIP initialisation in 3/3.

A second A/B isolated the backend path: with /dev/dxg present, DXG backend enabled succeeded in 3/3 runs, while disabling DXG backend detection failed in 3/3. The evidence supports /dev/dxg with ROCDXG/HSA/HIP userspace as the validated WSL GPU path rather than native Linux /dev/kfd passthrough. No Microsoft source patch was required by the tested configuration.

The claim is bounded to the tested Strix Halo gfx1151 environment and does not claim universal compatibility across AMD GPUs or application workloads.

Read the Microsoft WSL #40988 causal validation report DOI 10.5281/zenodo.23469296

ACE K2 independently built and physically validated a source-level correction for ROCm/rocm-systems #12571 on Windows gfx1151 / Radeon 8060S. Using matched TheRock/rocm-systems source provenance and the same build route, a forced-pristine build reproduced the targeted stale-read failure at 50/50, while the forced-patched build returned all six test cells clean at 50/50 with SDMA enabled.

The result is deliberately bounded to the tested Windows gfx1151 environment, matched source/runtime revision and governed #12571 reproducer matrix; it is not a claim of universal correctness across ROCm platforms or releases.

Read the ROCm #12571 validation report DOI 10.5281/zenodo.23267518

ACE K2 was applied to the existing public Windows/gfx1151 MIOpen Conv3d issue tracked as ROCm/TheRock #5845. The investigation reproduced a size-dependent failure boundary, isolated the failing backend path and produced a scoped experimental workaround candidate. ACE still terminated the formal evaluation as INCONCLUSIVE because repeated validation and numerical-equivalence testing against a declared tolerance were not completed.

This is a useful example of the intended governance model: a technically interesting result can be retained and published without allowing the system to promote it beyond the evidence available.

Read the MIOpen Conv3d technical white paper