Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
CMake
CMake
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3,191
    • Issues 3,191
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 11
    • Merge Requests 11
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • External Wiki
    • External Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • CMake
  • CMakeCMake
  • Issues
  • #17963

Closed
Open
Opened May 04, 2018 by Henry Schreiner@henryiiiContributor

CUDA: add support for architecture detection in a general way

Currently, CUDA as a language is missing architecture specifications. This should be added to allow users to migrate from FindCUDA. The first implementation, !1975 (closed), simply adapted the old function to make it a usable module for the CUDA language.

Injecting --generate-code= flags like this assumes that NVCC is the compiler. Other compilers may use other flags (e.g. Clang's --cuda-gpu-arch=). COMPILE_OPTIONS is typically meant for project code to set to add flags for which CMake offers no other abstraction. Low-level things like CUDA architecture selection should have first-class abstractions in CMake.

For example, we could have a CUDA_ARCHS target property and INTERFACE_CUDA_ARCHS equivalent for propagating usage requirements. The generators would transform this into the proper flags for the current compiler. VS generators could generate the proper .vcxproj file content without having to map flags.

Here's my summary of the proposed design:

  • Add two new properties, CUDA_ARCHS and INTERFACE_CUDA_ARCHS, that start empty and accept a list of numerical values.
  • Add a CMAKE_CUDA_ARCHS variable to initialize
  • Use a modified version of cmake_cuda_arch_select in !1975 (closed); it should only give a list of numerical arches as a result that could be used to set the CUDA_ARCHS. This would be the only part that needs to know about actual CUDA versions and allowed arch values.
  • The old version of the function could convert arch values into flags
  • NVCC generator would convert to flags as needed. Other generators, like clang, would be able to translate the numerical list into their correct flags (see #16586 (closed))

Thoughts:

  • Think about arch vs. code flags. Could virtual/code architecture be abstracted away, or are two variables needed, CUDA_ARCHS and CUDA_CODES?
To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: cmake/cmake#17963