Hm.. each option here is yet another kernel build. Longer build and fatter binary. I would say, that we do not need all possible combinations, if the target is defined by the arch name. "12.0;12.1" most probably should be just 12.1. The same for 10.x variations, if pure 10.0 devices do not exist and 10.3 is minimal production version.

Hello,
In CUDA 13
10.0 is b100/b200 same for aarch64 (gb200)
10.3 is GB300
11.0 is Thor with new OpenRm driver (moves to SBSA)
12.0 is RTX/RTX PRO
12.1 is Spark GB10

feel free to change it or recommend me the most optimized codegen there

Orin is moving to sbsa (deletes old nvgpu) in Q1 2026. I don’t if it will mantain the same codegen

There is new option that is putting f 10.0f and takes optimizarion for all blackwell family

@johnnynunez Do you have any official documentation mentioning the new compute capabilities and the f option?

@johnnynunez Do you have any official documentation mentioning the new compute capabilities and the f option?

https://developer.nvidia.com/blog/nvidia-blackwell-and-nvidia-cuda-12-9-introduce-family-specific-architecture-features/

Hm.. each option here is yet another kernel build. Longer build and fatter binary. I would say, that we do not need all possible combinations, if the target is defined by the arch name. "12.0;12.1" most probably should be just 12.1. The same for 10.x variations, if pure 10.0 devices do not exist and 10.3 is minimal production version.

@asmorkalov @johnnynunez @tomoaki0705 Firstly I don't really know what the use case for specifying the CUDA architecture is? That said if someone explicitly selects it I don't see the issue in compiling for all architectures because the user should be aware of the implications of there choice.

I think where the size is an issue is when the CUDA_ARCH_BIN and CUDA_ARCH_PTX are not specified and all supported architectures from all generations are built. In a future PR we could relax this and just build major architectures (5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0 and 12.0), equivalent to the CMake all-major flag.

A better alternative might be to make the default CUDA_GENERATION=Auto which I think makes much more sense. If a user hasn't explicitley specified the architechture this is probably what they want. We could then have an additional option equivalent to the existing default (CUDA_GENERATION=All) or one for building compatibility with all major architectures (CUDA_GENERATION=All-Major)