Getting PyTorch + ROCm Working on a Framework 13 (Ryzen AI 9) Using a Dev Container

2025/11/23

I’ve been using a Framework Laptop 13 with the AMD Ryzen AI 9 HX 370 as my lab machine with local model experimentation, learning etc..

On paper, it’s a perfect little AI dev box:

What I wanted was straightforward: get PyTorch + ROCm running on the integrated GPU without turning the host into a science project.

That was… optimistic.

This post walks through why running PyTorch directly on the host was painful, how I ended up with a Docker-based dev container, and the one obscure setting that made the whole thing finally work:

"containerEnv": {
  "HSA_OVERRIDE_GFX_VERSION": "11.0.0"
}

The working dev container lives here if you want to jump straight to the code: cicorias/devcontainer-pytorch-amd-rocm-ryzen-ai-9.1

The obvious approach: just install ROCm + PyTorch on the host

My first attempt was the “by the book” path:

  1. Install AMDGPU/ROCm drivers on the host.
  2. Follow AMD’s PyTorch-on-ROCm guidance with pip or the ROCm wheels.2
  3. Create a Python env, install PyTorch with ROCm, run torch.cuda.is_available() and call it a day.

In reality:

After a couple of cycles of “works in one shell, explodes in another”, I stopped treating this as a host configuration problem and started treating PyTorch + ROCm as an appliance problem.

Moving PyTorch + ROCm into a dev container

Instead of building the stack on the host, I leaned on a strategy AMD itself recommends: use a pre-built Docker image with PyTorch and ROCm that they actually test.

I ended up using this base image in a VS Code dev container:

rocm/pytorch:rocm7.1_ubuntu24.04_py3.12_pytorch_release_2.8.0

That image gives me:

The repo wraps this in a VS Code devcontainer definition so that opening the folder and choosing “Reopen in Container” gives you a fully configured PyTorch + ROCm environment on Ryzen AI.1

The split looks like this:

The most important one of those env vars is HSA_OVERRIDE_GFX_VERSION.

The critical HSA_OVERRIDE_GFX_VERSION knob

On current Ryzen AI / RDNA3-based iGPUs, ROCm isn’t always fully wired up out of the box. A common workaround is to tell the HSA runtime to pretend the GPU is a specific GFX version using HSA_OVERRIDE_GFX_VERSION.

You’ll see this pattern in various community threads: map GPU families to graphics core (GFX) versions and use HSA_OVERRIDE_GFX_VERSION to get ROCm to treat newer hardware as a supported class.7

For RDNA 3–class GPUs (like the Radeon 890M in the Framework 13), the value that worked for me was:

HSA_OVERRIDE_GFX_VERSION=11.0.0

Without that, I saw behavior like:

Once I set this inside the container, things snapped into place:

Because I wanted this to be automatic in VS Code, I put it in the containerEnv section of .devcontainer/devcontainer.json:

"containerEnv": {
  "HSA_OVERRIDE_GFX_VERSION": "11.0.0"
}

That one line is the difference between “this laptop is useless for PyTorch” and “this is a perfectly fine dev box.”

Wiring the GPU into the container

The other critical piece is giving the container access to the actual GPU devices.

In this setup, the container gets:

The devcontainer uses runArgs to pass those through and ensure the container’s user is in the right group:

"runArgs": [
  "--device=/dev/kfd",
  "--device=/dev/dri",
  "--group-add=video",
  "--ipc=host",
  "--shm-size=8g"
]

A few notes:

Why this pattern matters

On newer AMD hardware like the Ryzen AI 9 HX 370, support is evolving:

If you try to line all of that up on the host, you get:

By using:

you get a few non-obvious benefits:

  1. Reproducibility
    Clone the repo on another Ryzen AI machine, open in VS Code, “Reopen in Container”, and you’re running the same stack.
  2. Host sanity
    Your host Python environments stay clean. If ROCm or PyTorch break on some future update, it’s a container rebuild, not an OS reinstall.
  3. Clear abstraction boundary
    The host is responsible for:
    • GPU drivers
    • Docker
      The AI/ML stack lives entirely in the container and can evolve independently.
  4. Easy upgrades
    When AMD publishes a new rocm/pytorch tag (e.g., a newer ROCm or PyTorch), you bump the image reference in devcontainer.json and test it without touching the host.

In short: containers let you treat PyTorch + ROCm on AMD as an appliance, and HSA_OVERRIDE_GFX_VERSION=11.0.0 is the knob that actually lets that appliance talk to the Ryzen AI GPU.

Full .devcontainer/devcontainer.json

Here’s a self-contained .devcontainer/devcontainer.json that has been working on the Framework 13 / Ryzen AI 9:

{
  "name": "pytorch-rocm-ryzen-ai-9",
  "image": "rocm/pytorch:rocm7.1_ubuntu24.04_py3.12_pytorch_release_2.8.0",

  // Give the container direct access to the AMD iGPU
  "runArgs": [
    "--device=/dev/kfd",
    "--device=/dev/dri",
    "--group-add=video",
    "--ipc=host",
    "--shm-size=8g"
  ],

  // Critical for Ryzen AI / RDNA3-class iGPUs
  "containerEnv": {
    "HSA_OVERRIDE_GFX_VERSION": "11.0.0"
  },

  // Install your Python deps into an isolated venv
  "postCreateCommand": "python -m venv /opt/venv && /opt/venv/bin/pip install -r requirements.txt",

  "remoteUser": "root",

  "customizations": {
    "vscode": {
      "settings": {
        "python.defaultInterpreterPath": "/opt/venv/bin/python",
        "jupyter.jupyterServerType": "local"
      },
      "extensions": [
        "ms-python.python",
        "ms-toolsai.jupyter",
        "GitHub.copilot-chat"
      ]
    }
  },

  "features": {}
}

A minimal requirements.txt to go with it:

jupyterlab==4.5.0
matplotlib==3.10.7
pandas==2.3.3
scikit-learn==1.6.1
# add any other project-specific deps here

That’s essentially what the devcontainer-pytorch-amd-rocm-ryzen-ai-9 repo contains, just trimmed down for the core scenario.1

Verifying that the GPU is actually being used

Once the container is up:

Then verify from Python:

import torch

print(f"PyTorch version: {torch.__version__}")
print(f"ROCm available: {torch.cuda.is_available()}")

if torch.cuda.is_available():
    print(f"GPU device: {torch.cuda.get_device_name(0)}")
    x = torch.randn(1024, 1024, device="cuda")
    y = torch.matmul(x, x)
    print("Matmul OK on GPU, shape:", y.shape)
else:
    print("No ROCm GPU detected")

Open a terminal inside the devcontainer and run:

rocm-smi

You should see your GPU entry (Radeon 890M / GFX11-class).

If torch.cuda.is_available() is False, the first things to check:

Running the same setup without VS Code (plain Docker)

If you don’t want to use VS Code devcontainers, the equivalent raw docker run command is:

docker run -it --rm \
  --device=/dev/kfd \
  --device=/dev/dri \
  --group-add video \
  --ipc=host \
  --shm-size 8g \
  -e HSA_OVERRIDE_GFX_VERSION=11.0.0 \
  -v "$PWD":/workspace \
  -w /workspace \
  rocm/pytorch:rocm7.1_ubuntu24.04_py3.12_pytorch_release_2.8.0 \
  bash

From there you can:

python -m venv /opt/venv
source /opt/venv/bin/activate
pip install -r requirements.txt
python your_script.py

Same environment, just without the VS Code glue.

Footnotes

More Posts

2025/12/22 Fixing mise shims not working in VS Code on Ubuntu: avoid the Snap build
2025/12/11 Getting Azure Defender Security Scores into JSON
2025/09/04 Windows 11 with Bypass
2025/08/27 PXE with UEFI should be easy, right