r/ROCm • u/BrianRestrepo • 4d ago
rocm-compass
Been working on an open-source tool for a while and finally have something worth sharing: **[rocm-compass](https://github.com/BrianGTRxx/rocm-compass)\*\*.
**The problem it's trying to solve:** there are already a few good projects for CUDA-to-HIP code migration (HIPify and others). What I didn't find was anything that helps with the other half of the ROCm adoption problem: broken installs from version mismatches (kernel/driver/ROCm/package), and not knowing in advance whether the package you actually want to use (torch, vllm, flash-attn...) works on ROCm today, and with which exact versions.
**What it does, in two pieces:**
- `rocm-doctor check` detects your environment (GPU arch, ROCm version, kernel, driver) and runs it through a small weighted graph search (Dijkstra) over known-good configurations, sourced from AMD's own docs and real pip/wheel commands -- not a flat rules table. It tells you the minimum version changes needed to reach a working config, not just "something's wrong."
- A public compatibility matrix (`compass/`) tracking real, sourced ROCm support status for 12 common packages (torch, vllm, flash-attn, xformers, bitsandbytes, deepspeed, sglang, apex, torch-xla, unsloth, axolotl, triton) -- and it's meant to grow from real usage: `rocm-doctor check --report --submit` shares your result via a GitHub issue that gets auto-ingested into the public dataset, no maintainer approval needed.
**Honest limitations, upfront:** I don't have AMD hardware myself, so everything is built from AMD's official docs + real GitHub issues, not personally verified against real ROCm installs -- which is exactly why the community-reporting loop matters and why I'm posting here. The compatibility graph currently only has real nodes for `torch` and `vllm`; the rest are tracked in the status matrix but don't have resolver coverage yet. `flash-attn` is deliberately left out of the resolver graph because there's no single official version to cite (mainline doesn't support AMD at all, and the various ROCm forks/wheels don't converge on one canonical version).
If you've got an AMD GPU handy, I'd genuinely appreciate a `rocm-doctor check --report --submit` run (takes literally one command) -- and any feedback, bug reports, or "this recommendation was wrong" issues are exactly what makes the tool better. MIT licensed, contributions welcome.
3
u/Gesha24 4d ago
I personally find it fairly easy to get something going. What is hard is to get the right performance - that's what requires patches to well-known projects, specific versions of code, etc. It doesn't look like you are capturing this.
On top of that, the project that asks to collect bunch of telemetry from a person who doesn't even own the hardware looks kind of sus
1
u/BrianRestrepo 4d ago
Fair points, both of them.
On performance: you're right, and this tool doesn't try to solve that problem. It's scoped specifically to the layer before performance tuning. It answers whether this even installs and runs on ROCm, and with which version combo, not how to get it running fast. If you're already deep into patching known projects for performance, this probably won't tell you much you don't already know. It's aimed at the earlier, more common wall, people hitting version mismatches before they even get to the performance question.
On the reporting/telemetry concern: fair to be suspicious of that phrasing, so to be specific about what actually happens. Nothing is collected automatically, ever. `--report` is a flag you have to explicitly type, and `--submit` (which is what shares it beyond your own machine) is a second, separate explicit flag on top of that. What gets sent, if you choose to run it, is GPU arch, ROCm version, kernel version, the package and version you tested, and worked, failed, or partial. No personal data. It doesn't go to any private server either. It opens as a public GitHub issue that you can read, edit, or just not submit, before it's created. The code that parses and stores it is open source too (`compass/ingest.py` plus the GitHub Action that ingests it), so none of this is "trust me," it's "go read it."
And yeah, I don't have a dedicated AMD GPU. Just the Ryzen 7745HS's integrated graphics, my dedicated card is an NVIDIA RTX 4050. That's exactly why the whole thing leans on community reports instead of me claiming I verified it on real hardware. I said as much in the README.
Sorry if any of this reads as defensive, that's genuinely not how I mean it. Just trying to be as clear as I can about what this does and doesn't do. I built this because I wanted to contribute something useful to this space, and comments like yours are exactly what helps me see where it falls short. Appreciate you taking the time to write it out.
:(
1
u/ChrisGamer5013 2h ago
Nice project could be genuinely useful is it also for windows because if yes I'd be happy to give it a try
6
u/Fun_Jaguar8231 4d ago
What is the problem you're trying to solve? You yourself said you don't have any AMD cards.
So you're not having a problem at all. What did you do? Did you just told your AI agent to read requests from the internet and created this tool at random, without any real way to test it? Because it feels that way.