Skip to content

[Caspar] Replace legacy FindCUDA with modern CMake CUDA language support + minor compile function improvements#457

Closed
tordnat wants to merge 6 commits into
symforce-org:mainfrom
tordnat:tordnat/caspar-improve-cuda-compatability
Closed

[Caspar] Replace legacy FindCUDA with modern CMake CUDA language support + minor compile function improvements#457
tordnat wants to merge 6 commits into
symforce-org:mainfrom
tordnat:tordnat/caspar-improve-cuda-compatability

Conversation

@tordnat
Copy link
Copy Markdown
Contributor

@tordnat tordnat commented Apr 29, 2026

  • Replaces deprecated FindCUDA with CMake's native CUDA language support (requires CMake 3.18)
  • Fixes non-portable behavior from -arch=sm_75. It embeds only sm_75 SASS with no PTX, so on newer architectures the driver silently falls back to running Turing SASS under backward compatibility. I experienced that results can differ across GPU generations when this flag was set. The new CMAKE_CUDA_ARCHITECTURES embeds SASS for sm_75/80/86/89 and PTX for forward JIT-compatibility on future architectures. The logic is to by default have maximum compatability, and let the user specify the specific arch if they want to reduce binary size etc.
  • Respects CUDACXX env var before project() to handle systems with conflicting CUDA installations
  • CasparLibrary.compile() gains cuda_architectures and jobs parameters. The latter defaults to a single job to avoid OOM on machines where parallel CUDA compilation exhausts RAM (I only have 16gig rn, so this was an issue even with just a small amount of kernels)
  • Fixes CMake dev warning by adding DOWNLOAD_EXTRACT_TIMESTAMP TRUE to the pybind11 FetchContent_Declare
  • Some minor improvements to the compile() function hopefully making it easier to build

I have tested this on sm_86 and sm_89 GPUs.

@tordnat
Copy link
Copy Markdown
Contributor Author

tordnat commented Apr 29, 2026

For reference: This was discovered while unit testing the ongoing integration of Caspar into Colmap. Would be very nice to have build files that work more nicely with larger project, hence my contribution. colmap/colmap#4018

Copy link
Copy Markdown
Member

@aaron-skydio aaron-skydio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, just one question, otherwise looks good - thanks for the excellent description

Comment thread symforce/caspar/source/templates/buildfiles/CMakeLists.txt.jinja Outdated
Copy link
Copy Markdown
Member

@aaron-skydio aaron-skydio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I'll get this merged

@tordnat
Copy link
Copy Markdown
Contributor Author

tordnat commented May 2, 2026

Sorry for the last minute change. Added an option to make compiling the Python bindings optional, as some projects may only use the C++ library.

@tordnat
Copy link
Copy Markdown
Contributor Author

tordnat commented May 2, 2026

Sorry for the last minute change. Added an option to make compiling the Python bindings optional, as some projects may only use the C++ library.

This should also be an option in the generate function. Will make a new PR based on this branch.

aaron-skydio pushed a commit that referenced this pull request May 5, 2026
[Caspar] Python bindings opt-out

Projects embedding only the CXX/CUDA core of Caspar (e.g. via ExternalProject_Add) can now skip pybind11 entirely:
- `CasparLibrary.generate(..., python_bindings=False)` skips generating pybinding.cc, caspar_mappings_pybinding.h, solver_pybinding.h, and .pyi stubs
- The generated CMakeLists.txt omits the pybind11 find/fetch block and pybind11_add_module target entirely when python_bindings=False
- When python_bindings=True (default), a CASPAR_BUILD_PYTHON_BINDINGS CMake option is still emitted for compile-time opt-out
- All existing callers are unaffected since the default is True

Blocked by #457 and requested by colmap/colmap#4018 such that we don't have to manually remove python bindings when regenerating.

Closes #459

GitOrigin-RevId: 69b58a493f5a92e32174577cdfb6cb057f47fb24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants