Switch from FindCUDA to the FindCUDAToolkit

[tgrant-nv]

Description

This PR replaces use of the deprecated FindCUDA module with CMake's newer FindCUDAToolkit.

This change is a spiritual successor to Mark's old PR #2073. The overall direction remains the same, but has been reworked on top of the current state of main.

We're including some additional fixes discovered while testing the build on Windows.

FindCUDAToolkit Migration

The build now uses checked_find_package(CUDAToolkit) and CMake's imported CUDA runtime targets.

The migration:

• Uses the canonical CUDAToolkit_* variables internally, while continuing to accept CUDA_TOOLKIT_ROOT_DIR as a legacy fallback input.
• Links CUDA::cudart or CUDA::cudart_static rather than manually locating the CUDA runtime and appending Unix-specific system libraries.
• Passes the complete CUDA toolkit include list to NVCC and Clang.
• Adds the relocated CUDA C++ Core Libraries (include/cccl) when necessary for CUDA 13 and older supported CMake versions.
• Updates the remaining build and test logic to use CUDAToolkit_FOUND, CUDAToolkit_VERSION, and purpose-specific OSL variables rather than recreating the old FindCUDA result variables.
• Uses platform-aware CTest runtime paths so CUDA and NVRTC shared libraries can be found on both Windows and Unix-like systems.
• Uses VERBATIM custom commands so paths containing spaces are handled correctly.

Windows Device Alignment Fix

Testing on Windows revealed a separate incompatibility in the CUDA renderer support library. When building with older MSVC versions, Clang CUDA builds can resolve __builtin_assume_aligned to an MSVC host-only declaration, producing an error when it is used in device code.

We added a typed device_assume_aligned helper. It uses __builtin_assume to express the alignment guarantee on Windows and retains __builtin_assume_aligned on other platforms. The helper preserves the pointer type and evaluates each argument only once.

Standalone CUDA Example

We also migrated the standalone example-cuda project to FindCUDAToolkit. The build now reaches CUDA source compilation but encounters a pre-existing use of the now-defuct OSL/device_string.h API. Updating the example to OSL's current hash-based device string interface will be handled in a separate PR.

The removed cuda_compile_ptx helper is replaced with a local NVCC custom command, and the example links directly against the CUDA::cudart, CUDA::nvrtc, and CUDA::cuda_driver imported targets.

The example now propagates its complete dependency include paths into PTX compilation and uses sm_75 as its default architecture with CUDA 13, which no longer supports the previous architectures. Older CUDA versions retain an sm_60 default, and CUDA_TARGET_ARCH may still be overridden explicitly.

Tests

We did not add any new tests, and we didn't observe any change in the test results relative to the baseline.

Linux configurations were exercised with CUDA 12.8 through 13.3 and LLVM 15.0.7 through 22.1.8, including the following combinations:

• CUDA 12.8 / LLVM 15.0.7
• CUDA 12.9 / LLVM 18.1.0
• CUDA 13.0 and 13.1 / LLVM 20.1.8
• CUDA 13.3 / LLVM 22.1.8
• CUDA 13.3 / LLVM 20.1.8
• CUDA 13.3 / LLVM 15.0.7

Additional configuration and build checks covered:

• CMake 3.24.4 and 4.0.4.
• Dynamic and static CUDA runtime targets.
• The legacy CUDA_TOOLKIT_ROOT_DIR input.
• CUDA 13's relocated CCCL headers with an older supported CMake.
• CUDA/OptiX test runtime paths on Linux and Windows.
• CUDA 12.4 and 13.3 installations on Windows.
• CUDA installation paths containing spaces.
• Loading cudart and NVRTC with an otherwise clean Windows PATH.

Checklist:

• I have read the guidelines on contributions and code review procedures.
• I have read the Policy on AI Coding Assistants
  and if I used AI coding assistants, I have an Assisted-by: TOOL / MODEL
  line in the pull request description above.
• I have updated the documentation if my PR adds features or changes
  behavior.
• I am sure that this PR's changes are tested in the testsuite.
• I have run and passed the testsuite in CI before submitting the
  PR, by pushing the changes to my fork and seeing that the automated CI
  passed there. (Exceptions: If most tests pass and you can't figure out why
  the remaining ones fail, it's ok to submit the PR and ask for help. Or if
  any failures seem entirely unrelated to your change; sometimes things break
  on the GitHub runners.)
• My code follows the prevailing code style of this project and I
  fixed any problems reported by the clang-format CI test.

Assisted-by: OpenAI Codex / GPT-6

[lgritz]

LGTM

Thanks for this, it would have taken me a long time to work out myself!

[lgritz]

The Windows CI failures are totally unrelated, I understand them and will address them separately. So I'll merge this now.