Fix version macro and PyTorch 2.10 build error#423
Merged
Conversation
matthewdcong
force-pushed
the
pytorch_310
branch
from
01c80a3 to
163f468
Compare
harrism
approved these changes
Jan 22, 2026
Contributor
|
Thanks @matthewdcong ! |
matthewdcong
force-pushed
the
pytorch_310
branch
4 times, most recently
from
6bec33d to
71b914a
Compare
matthewdcong
force-pushed
the
pytorch_310
branch
from
71b914a to
d248392
Compare
matthewdcong
added a commit
that referenced
this pull request
Jan 22, 2026
PyTorch 2.10 was released today which introduces an API change which breaks compilation. Even with the relevant fixes, it still leads to a `CUBLAS_STATUS_INVALID_VALUE` mismatch on the unit tests. Pin the PyTorch version to 2.9.1 to workaround these issues for now. For more information, refer to #423 and pytorch/pytorch#170676 Signed-off-by: Matthew Cong <mcong@nvidia.com>
matthewdcong
force-pushed
the
pytorch_310
branch
from
d248392 to
850267f
Compare
This reverts commit 8038f76. Signed-off-by: Matthew Cong <mcong@nvidia.com>
Signed-off-by: Matthew Cong <mcong@nvidia.com>
Signed-off-by: Matthew Cong <mcong@nvidia.com>
Signed-off-by: Matthew Cong <mcong@nvidia.com>
Signed-off-by: Matthew Cong <mcong@nvidia.com>
Signed-off-by: Matthew Cong <mcong@nvidia.com>
matthewdcong
force-pushed
the
pytorch_310
branch
from
850267f to
4d21d9e
Compare
Signed-off-by: Matthew Cong <mcong@nvidia.com>
Signed-off-by: Matthew Cong <mcong@nvidia.com>
Signed-off-by: Matthew Cong <mcong@nvidia.com>
Signed-off-by: Matthew Cong <mcong@nvidia.com>
Signed-off-by: Matthew Cong <mcong@nvidia.com>
matthewdcong
force-pushed
the
pytorch_310
branch
from
48c3eae to
ede3b2f
Compare
Contributor
Author
|
Due to the changes in the CI configuration, I needed to run the tests from a different PR with |
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
2 participants
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.
The return value of
allowFP16ReductionCuBLAShas been changed to an enum in PyTorch 2.10. Unfortunately, the return value of the enum when reinterpreted as a boolean/integer has also been changed so we need to#ifdefit using a version macro. Prior to PyTorch 2.10, allowing reduced precision returnedtruebut now allowing reduced precision returns the enum valueAllowReducedPrecisionWithSplitKwhich equals0.Furthermore, the other places in fVDB where we were relying on PyTorch version macros were not correctly including the header that defines the macros. While this still yields correct behavior for most recent PyTorch versions (>= 2.7), this should still be fixed up. This also silences two warnings that are showing up in the Conda CI as a result of these includes. These are likely due to GCC bugs and incorrect based on silencing of a similar error (and prior experience with NanoVDB).
Finally, certain cuBLAS calls in the PyTests fail with PyTorch 2.1.0 and the
cuda:13.0.1image. Upgrading tocuda:13.0.2fixes the issues. We haven't been able to reproduce these errors outside of Docker or in other Docker containers so it's unlikely worth additional investigation at least for now.