MOAT ports popular CUDA GitHub projects to ROCm/HIP, one repo at a time. Coverage is expressed as gates -- wave64, wave32, windows -- so a port is proven once each gate has an architecture that validated it on real hardware. It is driven by AI coding agents running through either Claude Code or Codex: intake screens a candidate, a planner analyses it, a porter applies the change on a fork in the AMD-Ecosystem org, a reviewer checks it, and a validator runs the real tests on AMD GPUs. Submitting the result upstream, and everything that follows with a maintainer, stays with a person. This repo is the control plane; it tracks progress and holds the porting knowledge in the cuda-to-rocm skill.
Prefer pictures? VISUAL.md walks through all of this in twelve diagrams.
- If you maintain a project we might send a pull request to
- How it works
- What a person decides, and what agents may never do
- Suggest a project to port
- Licence
- Scope and honesty
- Projects
- Layout
Read this section and skip the rest; it is what concerns you.
Every pull request from this effort is written by an AI agent and read by a person before it is opened. It says so in its own body, along with a link back here. The person who approves it is approving the diff, the title and the body together, on one page, before any of it is visible on your repository.
You get at most one pull request per project. It is opened from a fork under the AMD-Ecosystem organisation against your default branch. There is no bot that follows up on a schedule -- every reply to you is a separate decision by a person, in a session they are sitting in front of.
We do not open it until the port has been built and its real test suite has been run on AMD hardware, on both wavefront widths (see the table below) -- that is where a CUDA port most often breaks. A compile is not evidence and does not count.
You can tell us to stop, and that is the end of it. No reason needed. Either:
- comment on any pull request of ours saying so, or
- open an opt-out issue naming your username, your organisation, or one repository.
An owner-level opt-out covers everything you own, including repositories nobody here
has looked at yet. It is recorded in data/optout.json, and it is
not a promise to remember: the record is enforced in three places in the tooling --
your repositories drop out of the candidate list, no project can be adopted from them,
and nothing can be submitted to them even if the port is already finished and approved.
Closing anything of ours still open and deleting the fork are done by a person, because
anything that touches your repository always is. Withdrawing an opt-out needs a person
on our side and someone asking on yours; an agent may carry that decision into the
record but never make it.
If a pull request is not how you would like to receive this, say that instead. Filing an issue with the findings and no code, or waiting for a release window, is a smaller ask than stopping and we would rather do it.
Five agents run in sequence, and each hands over through a state file rather than a conversation, so either supported agent harness on any host can pick up where the last one stopped: intake screens a candidate for licence and viability, planner analyses the build system and the CUDA surface, porter writes the port on the fork, reviewer reads the diff, and validator builds it and runs the project's own tests on a real AMD GPU. The reviewer and the validator can both send it back to the porter. What happens after approval -- submitting the pull request, maintainer rounds, merge -- is not a pipeline stage, because every step of it ends at a person. The submission itself runs only in an attended session; an agent may run that one command, since what it publishes was already approved wholesale on the review PR.
Each project gets a folder under projects/ holding its plan, notes, and a per-platform status file. A fresh Claude Code or Codex run in this repo detects its AMD architecture, finds the next actionable project, and continues the pipeline. No platform leads: whichever host picks the project up first does the porting, and the rest validate the same fork branch independently and in parallel, since the AMD targets share one unified ROCm port.
A platform is an architecture on an operating system, and it carries the gates implied by both -- its wavefront size, which is fixed by the architecture, and its OS. The same GPU on a different OS is a different platform covering different gates. A gate is satisfied once any one platform carrying that attribute has validated, so the gates can be covered by as few as two hosts.
Four decisions are held by a person. Each is enforced by the tooling rather than by an instruction an agent is asked to remember, and none of them is a checkbox an agent can tick on its own.
| the decision | how it is made | what an agent may do |
|---|---|---|
| Is this project's licence one we may contribute to? | Two tiers are cleared in advance (config/licenses.toml): permissive licences, and the copyleft licences approved for contributing to third-party projects; anything else waits for a named person, one project at a time |
Read the licence and record which one it is. That is a fact. The clearance is not, and a record without a name satisfies nothing |
| Do we take this project up at all? | Someone creates the fork in the AMD-Ecosystem org. Agents have no permission to create one, so its existence is the decision and nothing else has to record it | Write the case for and against, and recommend |
| Do we decline it? | Screens collect into one issue, a person answers in prose, and merging a small pull request recording the declines is the record -- approving is impossible on a self-authored pull request, and the merge carries the same actor and timestamp | Write the case. Never the verdict |
| Does this port go upstream, exactly as written? | A review pull request on our own fork carries the diff, the title and the body together. A person approves it there, and their approval is bound to that commit and that text | Open the review pull request and read the answer. It may never write the approval line |
The last one is the gate that matters to a maintainer receiving this. An approval covers what was on screen when it was given: a commit pushed afterwards, or an edit to the title or body, voids it and the submission step refuses. That check compares GitHub against GitHub -- the commit the review was attached to against the branch tip now -- because the local record is a file agents can write and the approval is not.
Opening the upstream pull request is one command run by a person in their own session, never by an unattended job.
Anyone can ask for a CUDA project to be ported: file a port request. It lands in the same queue our own discovery feeds, and a person decides whether to take it up before any work starts.
MIT, matching the ROCm projects this work targets. See LICENSE. The ports themselves live on forks and stay under each upstream project's own licence; nothing in this repository changes that.
The project list below is a best-effort ranked union of targeted GitHub searches, not a census of every CUDA repo (GitHub search caps results per query and misses repos whose dominant language is not Cuda). Ports aim to be minimally invasive: for pure CMake projects we prefer enable_language(HIP) plus a single cuda-to-hip compat header; for pytorch extensions we rely on torch's build-time hipify. A CPU-only build smoketest proves compilation only; correctness is gated on real-GPU test runs. See the cuda-to-rocm skill.
Projects we will not port (already ported, already supported, can't be ported, or not a real target) are recorded with reasons in data/dispositions.json and kept out of the actionable list; utils/triage.py manages those decisions.
Coverage is proven per gate, not per machine. A gate is met once any AMD GPU with that property has run the project's real test suite. Which specific card did it is recorded in each project's status file.
| gate | what it covers |
|---|---|
wave64 |
data-center cards -- Instinct MI200/MI300 class (CDNA), 64 threads per wavefront |
wave32 |
desktop and workstation cards -- Radeon RX / PRO (RDNA), 32 threads per wavefront |
windows |
the port builds and runs on Windows, not only Linux |
A wavefront is AMD's analogue of an NVIDIA warp, which is always 32 threads. Code that silently assumes 32 is the single most common way a CUDA port breaks on AMD, so the two widths are proven separately rather than assumed to follow from each other.
| cell | meaning | outcome | meaning | |
|---|---|---|---|---|
| ✅ | proven on the current code | 🟣 | contribution merged upstream | |
| 🔄 | proven earlier; the code has moved since | 🟢 | pull request open | |
| 🔧 | in progress | 🔴 | pull request closed | |
| ⬜ | not started | ⚖️ | licence bars contributing the port | |
| 🚫 | blocked, with a reason recorded | ⚪ | set aside, with the reason recorded | |
| 🎫 | waived for this project, with maintainer approval | ⏸ | on hold, deliberately not being worked | |
| — | nothing recorded | — | nothing recorded |
The project name links upstream.
See VISUAL.md for a diagram walkthrough of everything above, projects/README.md for the per-project files, the cuda-to-rocm skill for porting strategy and fault classes, and AGENTS.md for how either supported agent harness drives the pipeline.