CUDA 13 - #143
Merged
Merged
Conversation
A static_assert in the vendored CUEW fork pinned the CUDA SDK to major version 12, so a CUDA 13 SDK failed to compile outright. Accept both majors from this branch rather than forking a 13-only one, so CUDA 12 users are unaffected. CUDA 13 leaves the driver API intact, but remaps several base names onto newer versioned symbols and drops parts of the runtime API: - cuda.h remaps 11 driver entry points (cuMemAdvise, cuEventElapsedTime, the cuGraph* dependency calls, ...) onto _v2 symbols, which collides with the generated _oro #define table. Drop the SDK mapping ahead of that region. - cuCtxCreate now resolves to cuCtxCreate_v4 and takes an extra CUctxCreateParams argument, so call cuCtxCreate_v2 explicitly. - cudart removed the _v2 exports of cudaGetDeviceProperties and the external semaphore calls, promoting the unsuffixed names to those signatures. Re-resolve those pointers from the names CUDA 13 actually exports. - cudaStreamGetCaptureInfo gained an edgeData_out argument, so it gets its own typedef plus an adapter back to the _v2 shape. - cudaDeviceProp lost nine fields; repopulate them via cudaDeviceGetAttribute. - cudaLaunchCooperativeKernelMultiDevice and cudaLaunchParams are gone, so the matching HIP shims now report hipErrorNotSupported. Only the static_assert change falls inside an Orochi Summoner region; the rest sits outside the markers so regeneration will not clobber it. Verified by compiling and linking against the 12.2, 13.0 and 13.3 SDKs, with no change to the CUDA 12.2 warning output. Not yet exercised on hardware, and the Windows DLL names come from NVIDIA's redist listings rather than from inspecting the DLLs. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The version list added with CUDA 13 support hardcoded the exact strings 13.0 and 12.2, so a v13.3 install matched nothing and silently fell back to the older SDK: the fallback happened before the generic CUDA_PATH backup, so a machine with 13.3 and 12.2 side by side built against 12.2 without any hint that the requested version had been ignored. Glob the install roots per supported major instead and keep the highest minor found, so 13.1/13.2/13.3 and future releases work without touching this list. The CUDA_PATH_V<major>_0 envvar is still honoured first for SDKs installed outside the standard folders. Verified against fixture directory trees in both the premake and CMake paths: highest-minor wins, 13.x is preferred over 12.x, 13.10 sorts above 13.9 numerically rather than lexicographically, the envvar overrides the glob, and the no-SDK case still warns. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
meistdan
requested review from
RichardGe and
shoikeda
and
a lite review from Copilot
August 5, 2026 07:25
There was a problem hiding this comment.
Pull request overview
Updates Orochi/CUEW integration to support building against CUDA 12.x and CUDA 13.x SDKs, accounting for CUDA 13 API/ABI surface changes and removed/renamed entry points.
Changes:
- Adjusts CUDA driver/runtime symbol wrangling and macro mappings to accommodate CUDA 13’s versioned symbol remaps and removed
_v2runtime exports. - Restores removed
cudaDeviceProp/hipDeviceProp_tfields on CUDA 13 viacudaDeviceGetAttribute, with explicit handling for removed cooperative multi-device launch support. - Updates build helper scripts (Premake/CMake) and documentation to detect/use CUDA 12/13 installs and describe CUDA 13 requirements/limitations.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| README.md | Documents CUDA 12/13 compatibility notes and CUDA 13 driver/GPU limitations. |
| Orochi/Orochi.cpp | Adds CUDA 13 macro undef/remap handling and a capture-info compatibility adapter; updates ctx creation to cuCtxCreate_v2. |
| Orochi/nvidia_hip_runtime_api_oro.h | Adapts property population and API wrappers for CUDA 13 removed fields/APIs and entry-point changes. |
| Orochi/enable_cuew.lua | Updates Premake CUDA SDK discovery to accept CUDA 12/13 majors and select highest installed minor. |
| Orochi/enable_cuew.cmake | Updates CMake CUDA SDK discovery to accept CUDA 12/13 majors and select highest installed minor. |
| contrib/cuew/src/cuew.cpp | Extends runtime DLL search for CUDA 13 on Windows; adds remap-aware symbol resolution and relaxes version asserts to CUDA 12–13. |
| contrib/cuew/include/cuew.h | Adds CUDA 13-specific typedef/pointer for updated capture-info entry point; minor formatting cleanup. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Review feedback: the CUDA 13 remap block re-resolved the _v2 cudart pointers from the unsuffixed export names unconditionally. That is only correct against a CUDA 13 runtime. A CUDA 12 cudart exports both spellings, and its unsuffixed entry points are the older ones: cudaGetDeviceProperties expects the pre-12 cudaDeviceProp, and cudaStreamGetCaptureInfo takes one argument fewer than the CUDA 13 signature the _v3 pointer is typed with, so arguments would land in the wrong slots. That mismatched pairing was reachable only because the previous commit added cudart64_12.dll as a fallback while building against CUDA 13 headers. It is not a sound pairing in the first place, since cudaDeviceProp differs between the two majors (95 fields vs 93), so pick the DLL matching the header major instead of falling back across majors. Guard the remap by the reported runtime version as well, because callers can still supply their own DLL through customPaths_CudaRT, and only fill pointers that are still null so a value resolved from the real name is never overwritten. The nvrtc path list stays multi-version: unlike cudart, no retained nvrtc function changed signature between 12 and 13, and the only removed exports (nvrtcGetNVVM/Size) are never called. Verified: compiles and links against 12.2, 13.0 and 13.3 with no undefined symbols, and the CUDA 12.2 warning output is unchanged. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Review feedback: the CUDA 13 capture-info adapter reported cudaErrorNotSupported whenever the v3 pointer was null, losing functionality against a runtime that still exports cudaStreamGetCaptureInfo_v2. The two spellings are mutually exclusive - only a CUDA 12 cudart exports _v2, only a CUDA 13 one exports the replacement - so preferring _v2 and falling back to the v3 adaptation is unambiguous. The _v2 signature is identical across both majors and uses only opaque handles and an enum, so calling it from a CUDA 13 build is ABI-safe. Note this is now only reachable when the caller supplies its own runtime through customPaths_CudaRT, since the default cudart path list matches the header major. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Review feedback: the CMake module accepted CUDA_PATH_V<major>_0 and the backup CUDA_PATH without checking that they point at an existing directory, and relied on cuda_path being unset on entry. Unlike the premake script, which gates its final decisions on oropremake_PathOK, the CMake tail tests cuda_path only for non-emptiness. A stale envvar therefore both masked an otherwise working install and enabled CUEW with a broken include directory. Reproduced with a bogus CUDA_PATH_V13_0 and a valid 12.2 on disk: it reported "CUDA SDK install folder found: /tmp/does-not-exist-13" instead of falling through. Validate every envvar with path_ok before accepting it, so cuda_path is always either empty or an existing directory and the later truthiness checks hold. Also initialise cuda_path explicitly, since include() does not open a new scope and the including project may already define that name. The premake script is unaffected and left alone. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.
Suppressed comments (3)
contrib/cuew/src/cuew.cpp:107
- Use the correct capitalization for GitHub in this comment.
// If this assert is wrong, it's advised either to install a CUDA SDK inside the supported major range, or search on the Orochi github a branch matching the CUDA SDK you are using.
Orochi/enable_cuew.cmake:88
- This WARNING is emitted before trying the CUDA_PATH and /usr/local/cuda fallbacks below, so it can warn “No supported version…” even when a valid CUDA SDK is found later. This produces misleading build output.
if(NOT cuda_path)
string(REPLACE ";" ".x or " supported_cuda_majors_pretty "${SUPPORTED_CUDA_MAJORS}")
message(WARNING "No supported version of CUDA for this Orochi is found: needs a ${supported_cuda_majors_pretty}.x SDK. It's advised that you install one of these versions.")
endif()
Orochi/enable_cuew.lua:79
- This warning is emitted before checking the CUDA_PATH fallback (and the default /usr/local/cuda symlink), so it can print “No supported version…” even when a usable CUDA SDK is found a few lines later. This is confusing/noisy for normal setups.
if (not oropremake_PathOK(cuda_path)) then
print("No supported version of CUDA for this Orochi is found: needs a " .. table.concat(supported_cuda_majors, ".x or ") .. ".x SDK. It's advised that you install one of these versions.")
end
Review feedback: both build scripts printed "No supported version of CUDA ... is found" before trying the CUDA_PATH envvar and the default /usr/local/cuda symlink, so a perfectly working setup that resolves through either of those was preceded by a spurious not-found message. The ordering predates this branch, but the wording used to name the single preferred version, which read as "the ideal SDK is missing". Generalising it to "no supported version is found" turned it into a claim that is simply wrong when a fallback succeeds a few lines later, so move it below the fallbacks. When nothing is found at all it still fires, alongside the existing message about CUEW being disabled. Also correct the capitalisation of GitHub in the version-assert comment. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
meistdan
marked this pull request as ready for review
August 5, 2026 09:53
takahiroharada
self-requested a review
August 13, 2026 20:31
takahiroharada
approved these changes
Aug 13, 2026
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
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.
Tested with the latest driver and CUDA 13.3 on Windows 11.
HIPRT unit tests are also passing.
This should resolve #129.