[ROCm] Fix round for #327: stage rocrand.dll on arch-suffixed ROCm wheels - #1
Merged
Conversation
The Windows runtime staging looked for the ROCm libraries package under the exact name _rocm_sdk_libraries. A ROCm wheel built for a single GPU architecture installs it as _rocm_sdk_libraries_<arch> instead, so the lookup found nothing, rocrand.dll was never copied next to the generated executable, and the run died before its first line of output: hiprand.dll imports rocrand.dll, and Windows resolves neither from PATH once the exe directory is searched first. Match the directory by prefix, and copy rocrand.dll unconditionally. It ships in the devel package too, so its presence never depended on locating the separate libraries package; the copy loop already skips names it cannot find. Assistance from an AI coding agent was used to prepare this change. Test Plan: Radeon 8060S (gfx1151), Windows 11, ROCm 7.14, which installs the libraries package as _rocm_sdk_libraries_gfx1151. Three standalone simulations covering plain integration, delayed synaptic propagation (the spikequeue.h spinlock) and a ~12000-synapse network: ``` set HIP_VISIBLE_DEVICES=0 set USE_HIP=1 python test_basic.py ``` Before: RuntimeError: Project run failed, the generated binary exiting 127. After: 3/3 pass; the state-update result matches the analytic solution to 6.7e-16.
jeffdaily
added a commit
to AMD-Ecosystem/moat
that referenced
this pull request
Aug 17, 2026
Collaborator
Author
|
/moat approve |
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.
Fix round on upstream PR brian-team#327, staged on
moat-fix-327(baseaca06c78, tip90d6d7cf).What prompted it
Not maintainer-requested. The windows-gfx1151 revalidation at the published tip found a genuine port defect in the Windows runtime staging: the DLL-copy logic looked for the ROCm libraries package under the exact directory name
_rocm_sdk_libraries, but per-architecture TheRock wheels install it as_rocm_sdk_libraries_<arch>(here_rocm_sdk_libraries_gfx1151). The lookup found nothing,rocrand.dllwas never copied, and the generated binary died at load (hiprand.dllimportsrocrand.dll) with exit 127 before any output. This would fail identically for any user on a single-arch ROCm wheel, so it is a port defect, not a host quirk.What changed
One commit,
90d6d7c(brian2cuda/device.py, +13/-9): glob_rocm_sdk_libraries*instead of matching an exact directory name, and copyrocrand.dllunconditionally (the copy loop already tolerates absent names —rocrand.dllalso ships in the devel package). Both edits sit inside the existingis_hip_backend() and os.name == 'nt'guard; the only unguarded line is a newimport glob. Linux behavior untouched.What revalidated (both at tip 90d6d7c)
nvidia-smi, unmodified by the port; not satisfiable on an AMD-only host).master..moat-fix-327(commits and added lines): clean. Fork tree clean.Upstream reply
Pushed one small fix to the Windows staging logic in device.py. ROCm Python wheels can be packaged per GPU architecture, and those installs name the bundled libraries directory with an architecture suffix; the previous exact-name lookup then missed it, so the generated binary failed to load rocrand.dll (a transitive import of hiprand.dll). The directory is now matched by prefix and rocrand.dll is copied alongside the other runtime DLLs. The change is confined to the existing Windows-only branch of the code, so Linux behavior is unchanged.
Re-ran the tests at the new commit on Windows (Radeon 8060S) and Linux (MI250X): simulations generate, compile, and run correctly on both, including the synaptic-delay spike-queue path.
No hurry on our end -- this just keeps the branch correct for anyone trying it on a per-architecture ROCm install while you sort out the review policy.
For our own record (not posted upstream)
The reply above is the only upstream-visible text; approving this PR covers the commit and that reply.
upstream.py --merge-fix --applythen fast-forwards brian-team#327's branch to90d6d7cfand posts the reply.