DEV Community

Cover image for I built a tool that migrates CUDA code to AMD ROCm — and made the AI do less, not more
GJV PAVANSAI
GJV PAVANSAI

Posted on

I built a tool that migrates CUDA code to AMD ROCm — and made the AI do less, not more

A huge amount of GPU code is locked to NVIDIA CUDA — nvcc in the build, cudaMalloc in the kernels, torch.cuda everywhere. Moving it to AMD ROCm (often cheaper and more available hardware) usually means reading the whole codebase by hand and rewriting every NVIDIA-specific line. Most teams never do it.

So I built ROCmPorter. Point it at any GitHub repo and it flags every CUDA dependency with file+line evidence, scores the repo's ROCm readiness 0–100, and can open a pull request that migrates the code to HIP.

Live (free, no signup): https://rocmporter-agent.vercel.app
Source (MIT): https://github.com/pavansai20052004-hue/rocmporter-agent

The one design decision I care about: make the AI do less

The obvious way to build this is "throw the file at an LLM and ask for HIP." I didn't do that, because most of a CUDA→HIP migration isn't a judgment call — it's a lookup. cudaMallochipMalloc. <cuda_runtime.h><hip/hip_runtime.h>. cudaStream_thipStream_t. Asking a model to do that is slow, non-deterministic, and occasionally wrong on things that have exactly one correct answer.

So the engine is deterministic-first:

  1. A curated hipify pass (~90 CUDA→HIP API/header/library mappings) runs first and converts the mechanical majority with zero AI. Files it fully converts never touch a model.
  2. Only the semantic remainder goes to an LLM — and that prompt is grounded in a small curated knowledge base of ROCm facts (warp size is 64 on CDNA, cuDNN→MIOpen isn't a rename, don't rewrite torch.cuda device strings on ROCm builds of PyTorch, etc.).
  3. Every migrated file reports provenance: what was mechanical vs. AI-assisted.

The result is that patches are mostly deterministic with a small, clearly-labeled AI remainder — which is exactly what you want when a human has to review the diff.

Compile-verified, not vibes

A migration tool that emits code that doesn't compile is worse than useless. So generated HIP is compile-checked with hipcc inside AMD's official rocm/dev-ubuntu-22.04 container in CI on every push. The example in the repo (examples/vector_add) is machine-generated by the engine and compile-validated continuously — the badge on the README is a real build, not a claim.

Being honest about the limit

It's compile-verified, not execution-verified. I don't have AMD GPU access yet, so I can't run migrated test suites on real hardware. That's the next thing I want to add, and I'd rather say it plainly than imply otherwise.

Stack

FastAPI backend (static analysis + hybrid engine), React frontend, and it also ships as a GitHub Action (readiness comments on PRs) and a VS Code extension (inline CUDA lock-in + one-click hipify).


If you've got a CUDA repo you've been meaning to port, paste it in and tell me where the output is wrong — that feedback is exactly what improves the mapping. And if it's useful, a GitHub star helps other people find it. 🙏

Top comments (0)