Add AMD GPU support via ROCm/HIP - #68
Open
jeffdaily wants to merge 2 commits into
Open
Conversation
Enable building FastGeodis on AMD GPUs with ROCm PyTorch. The existing CUDA kernels work on HIP through PyTorch's build-time hipify mechanism with no kernel-level changes needed. Changes: - setup.py: Detect ROCm PyTorch via ROCM_HOME when CUDA_HOME is not set, enabling the GPU build path on AMD systems - .gitignore: Exclude *.hip files generated during the hipify process The port is entirely automatic: PyTorch's CUDAExtension invokes hipify to translate the CUDA source at build time. All 4 kernels (2D/3D geodesic distance transforms, row/plane raster scans) use only standard CUDA runtime APIs and block-level synchronization that map 1:1 to HIP, with no warp-level intrinsics or textures. This work was developed with the assistance of Claude, an AI assistant by Anthropic. Test Plan: Built and tested on AMD MI250 (gfx90a) with ROCm 7.2 and PyTorch 2.13: ``` HIP_VISIBLE_DEVICES=0 PYTORCH_ROCM_ARCH=gfx90a pip install -e . --no-build-isolation python -m pytest tests/ -v ``` Result: 300 passed in 71.80s, covering 2D/3D geodesic distance transforms on both CPU and GPU paths.
c10.dll built with clang does not export the inherited constructor c10::ValueError(SourceLocation, string) because MSVC does not re-export inherited constructors from dllimport bases even for C10_API classes. MSVC-compiled extension .cpp files that include <torch/extension.h> trigger TORCH_CHECK_VALUE which generates a dllimport reference to that constructor, causing LNK2001. Fix: add a Windows-only /ALTERNATENAME linker directive in setup.py that redirects the missing ValueError(SourceLocation, string) dllimport thunk to Error(SourceLocation, string), which IS exported by c10.dll. ValueError IS-A Error with no additional data members; the constructors are semantically identical. Authored with Claude (claude-sonnet-4-6) as part of AMD ROCm porting. Test Plan: # Windows gfx1201 (RX 9070 XT, RDNA4, wave32) HIP_VISIBLE_DEVICES=0 PYTORCH_ROCM_ARCH=gfx1201 ROCM_HOME=<venv>/_rocm_sdk_devel DISTUTILS_USE_SDK=1 python.exe -m pip install -e . --no-build-isolation HIP_VISIBLE_DEVICES=0 python.exe -m pytest tests/ -v # Result: 300 passed
jeffdaily
added a commit
to AMD-Ecosystem/moat
that referenced
this pull request
Aug 7, 2026
…s it exposed The first real approval landed as an ordinary comment, not a review comment. That is the box GitHub puts in front of a reviewer, so requiring the other one was a design error, not a misclick. Both are accepted now. The forms are not equally strong and the code says which is which. A review comment is stamped with commit_id, so the gate compares it to the branch tip exactly. A conversation comment carries no commit and is judged by time instead: an approval is stale if the branch tip dates from after it. That catches the case that actually happens -- an agent pushing a fix after approval, stamped now -- and misses one that can: a commit authored locally before the approval and pushed after, since a committer date is not a push time. commit_id is used whenever it is there. Fixing that surfaced two holes. The tip's date came back None on every call, because `gh api --jq` emits a bare date string and _gh_json json-parses its output. The check I had just written was a no-op. It now reads the commit object, and refuses rather than passing when the date cannot be read: not knowing whether anything landed after an approval is not the same as knowing nothing did, and the precedent here is that an unreachable review PR refuses. And nothing ever checked the review PR was still open, so a closed one carrying a standing approval would still publish. Closing is the only stop gesture available short of requesting changes, it is reversible by reopening, and it is what --publish itself does after submitting. It now blocks. FastGeodis is submitted: masadcv/FastGeodis#68, title and body byte-identical to what was approved on the review PR. Test Plan: ``` python3 utils/upstream.py --publish # FastGeodis READY python3 utils/upstream.py --publish --apply # opened masadcv/FastGeodis#68 title/body compared between the review PR and the upstream PR -> identical approval_currency, forced through each outcome: as-is -> ok review PR CLOSED -> closed tip dated after approval -> stale-commits tip date unreadable -> unverifiable ``` Authored with Claude (Opus 5) as the AI assistant.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
FastGeodis currently builds its GPU extension only when
CUDA_HOMEis set, so on a ROCm PyTorch install the extension silently falls back to CPU. This adds AMD GPU support.The change is small because PyTorch does most of the work: its build-time hipify translates
fastgeodis_cuda.cuon the way through, so no kernel source changes were needed and the CUDA path is untouched.setup.pyalso checksROCM_HOMEfromtorch.utils.cpp_extension, soBUILD_CUDAis true on a ROCm install.CUDA_HOMEbehaviour is unchanged..gitignoreignores the*.hipfiles PyTorch generates during a ROCm build./ALTERNATENAMElink flag maps thec10::ValueError(SourceLocation, string)import toc10::Error(SourceLocation, string). A clang-builtc10.dlldoes not export the inherited constructor, so MSVC callers fail with LNK2001;ValueErrorderives fromErrorand adds no members, so the redirect is safe. It is guarded tosys.platform == "win32"and does not affect Linux or CUDA builds.Tested with
python -m pytest tests/(300 tests: 2D and 3D geodesic distance transforms, signed and unsigned, GPU and CPU):Both wavefront widths are covered: 64 on gfx90a and 32 on the RDNA parts. No CUDA hardware was available to re-run the NVIDIA path, but no CUDA-side source is modified.
This work was done with the assistance of an AI coding agent.