Build against CUDA 13 / CCCL 3 and fix gradcheck on torch >= 2.0 - #637
Open
kevintsq wants to merge 1 commit into
Open
Build against CUDA 13 / CCCL 3 and fix gradcheck on torch >= 2.0#637kevintsq wants to merge 1 commit into
torch >= 2.0#637kevintsq wants to merge 1 commit into
Conversation
CUDA 13 ships CCCL 3, which relocates the bundled Thrust/CUB headers and removes a number of APIs the 0.5.4 sources relied on. Five changes are needed to compile: - setup.py: CUDA >= 13 moved Thrust/CUB from <cuda>/include to <cuda>/include/cccl, so neither nvcc nor the host compiler finds them implicitly. Detect and add that directory. - coordinate_map_functors.cuh: thrust::unary_function is gone in CCCL 3. It only supplied argument_type/result_type typedefs, so declare them directly instead of inheriting. - coordinate_map_gpu.cuh: assigning the unique_ptr returned by map_type::create() to a shared_ptr makes libstdc++ call an unqualified __to_address(). map_type mentions cuda::std::pair under CCCL 3, so ADL also finds cuda::std::__to_address and the call is ambiguous. Build the shared_ptr from the released pointer to bypass that overload. - cudf/detail/nvtx/ranges.hpp: the vendored nvtx3.hpp predates the NVTX v3 headers CUDA >= 12 ships and PyTorch pulls in. Both declare an inline versioning namespace inside nvtx3, making every name in it ambiguous. These ranges are profiling annotations only, so build without them. - concurrent_unordered_map.cuh, coordinate_map_gpu.cu, spmm.cu: CCCL 3 dropped transitive includes, and CUDA 13 replaced the device-ordinal cudaMemPrefetchAsync overload with a cudaMemLocation one. Note that spmm.cu keeps upstream's single sort_by_key over a zip iterator. Splitting it into two sort_by_key calls on the same key array is not equivalent: the first sorts the keys in place, so the second computes an identity permutation and the values stop matching their (row, col) pairs. Separately, utils/gradcheck.py unconditionally forwarded check_sparse_nnz= to torch.autograd.gradcheck, which dropped that parameter in torch 2.0, so every gradient check raised TypeError. Forward it only when accepted, and map it to the replacement masked= argument otherwise. Verified on CUDA 13.0 / PyTorch 2.9.1+cu130 / Python 3.13 / gcc 13.3 / sm_120 (RTX 5090 and RTX PRO 6000 Blackwell). Convolution, pooling and coo_spmm agree bit-exactly between the CPU and CUDA backends forward and backward, and coo_spmm matches a reference COO product on unsorted input. The test suite's remaining failures are pre-existing test-code rot against torch 2.x and the pre-0.5 SparseTensor API, not regressions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
CUDA 13 ships CCCL 3, which relocates the bundled Thrust/CUB headers and removes a number of APIs the 0.5.4 sources relied on. Five changes are needed to compile:
Note that spmm.cu keeps upstream's single sort_by_key over a zip iterator. Splitting it into two sort_by_key calls on the same key array is not equivalent: the first sorts the keys in place, so the second computes an identity permutation and the values stop matching their (row, col) pairs.
Separately, utils/gradcheck.py unconditionally forwarded check_sparse_nnz= to torch.autograd.gradcheck, which dropped that parameter in torch 2.0, so every gradient check raised TypeError. Forward it only when accepted, and map it to the replacement masked= argument otherwise.
Verified on CUDA 13.0 / PyTorch 2.9.1+cu130 / Python 3.13 / gcc 13.3 / sm_120 (RTX 5090 and RTX PRO 6000 Blackwell). Convolution, pooling and coo_spmm agree bit-exactly between the CPU and CUDA backends forward and backward, and coo_spmm matches a reference COO product on unsorted input. The test suite's remaining failures are pre-existing test-code rot against torch 2.x and the pre-0.5 SparseTensor API, not regressions.