Repository navigation
Use OpenCV_CUDA_jll's CUDA build when it is installed - #104
Merged
Merged
Conversation
`OpenCV.set_backend!("cuda")` makes OpenCV load its binaries from
OpenCV_CUDA_jll instead of OpenCV_jll after a restart. The choice is made
at precompile time, so only one OpenCV build is ever loaded.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #104 +/- ##
==========================================
- Coverage 92.79% 89.28% -3.52%
==========================================
Files 11 11
Lines 236 252 +16
==========================================
+ Hits 219 225 +6
- Misses 17 27 +10 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Pkg downloads the CUDA runtime and cuDNN artifacts (about 1.8 GB) when OpenCV_CUDA_jll is installed, even if it is never loaded: the artifact selection hook of JLLs with CUDA platform augmentation includes lazy artifacts. As a hard dependency, every OpenCV user on a machine with an NVIDIA driver would pay for that. Instead, OpenCV_CUDA_jll is a weak dependency that users opt into with `] add OpenCV_CUDA_jll`. OpenCV's `__init__` uses it when it is installed and has binaries for the host, binding its `libopencv_julia`, which registers the same bindings as OpenCV_jll's, at `@initcxx`. This replaces the backend preference. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
OpenCV finds OpenCV_CUDA_jll anywhere on the load path, including stacked environments such as @v1.x, where OpenCV's [compat] entry is not enforced. Binding the wrappers to a libopencv_julia from another OpenCV release would fail or misbehave, so fall back to OpenCV_jll with a warning when the versions differ. Document the load-path behavior in the README. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
Author
|
@yakir12 FYI. |
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.
Adds opt-in CUDA support: after
] add OpenCV_CUDA_jlland a restart, OpenCV loads its binaries from OpenCV_CUDA_jll (CUDA 13 + cuDNN, Linux x86_64/aarch64) instead of OpenCV_jll. This enablescv.dnn'sDNN_BACKEND_CUDA. Removing OpenCV_CUDA_jll switches back to the CPU build.Requires JuliaPackaging/Yggdrasil#15546 (OpenCV_CUDA_jll 4.14.0+1) for the CUDA path; see below.
Design
.pkg/select_artifacts.jlhook of CUDA-augmented JLLs selects them withinclude_lazy=true. In a fresh depot on a GPU machine, a hard dependency made] add OpenCVdownload about 1.8 GB: CUDA_Runtime 1023 MiB, CUDNN 431 MiB, CUDA_Compiler 188 MiB, CUDA_Driver 108 MiB and OpenCV_CUDA 42 MiB. As a weak dependency, it adds nothing to the install. The[compat]entry still constrains its version when a user adds it.__init__. If OpenCV_CUDA_jll is in the environment and has binaries for the host, OpenCV loads it and points@wrapmodule's library callback at itslibopencv_juliabefore@initcxx. The wrappers stay precompiled against OpenCV_jll, which works because both libraries are built from this repo'sgen/. They register the same 859 bindings and export the same 25,836 symbols, and@initcxxre-resolves every function pointer by key. While output is being generated for precompilation, OpenCV always uses OpenCV_jll.@initcxxbinds the library inOpenCV.__init__, and extensions load only after their parent's__init__. There is also no preference to set: installing the package is the opt-in.libopencv_core_cuda.so.414, …) so the two builds don't clash by soname. With the currently registered OpenCV_CUDA_jll 4.14.0+0, which lacks the renaming, OpenCV warns and stays on the CPU build.Testing
Julia 1.13.3, 2× H100 NVL (driver 595.45, CUDA 13.2), OpenCV_jll 4.14.0+0:
Fresh depot,
] add OpenCV: no CUDA artifacts are downloaded (455 MB of artifacts in total, against 4.0 GB with a hard dependency), and OpenCV binds OpenCV_jll.With OpenCV_CUDA_jll from Yggdrasil#15546's CI added: 313/313 tests pass, OpenCV binds OpenCV_CUDA_jll, and both builds' libraries are loaded side by side.
With the registered OpenCV_CUDA_jll 4.14.0+0 added: OpenCV warns, binds OpenCV_jll, and 313/313 tests pass.
DNN face detector (
opencv_face_detector_uint8.pb, 300×300), with identical detections on all backends:DNN_BACKEND_OPENCV/DNN_TARGET_CPUDNN_BACKEND_CUDA/DNN_TARGET_CUDADNN_BACKEND_CUDA/DNN_TARGET_CUDA_FP16Modelhas no generatedsetPreferableBackendbinding, so the backend is set on aNetfromreadNetbefore wrapping it inDetectionModel.Not covered: CI here has no GPU and does not install OpenCV_CUDA_jll, so it only exercises the CPU path. I could not test a Linux machine without an NVIDIA driver, where OpenCV_CUDA_jll should have no binaries and OpenCV should stay on the CPU build.
Bumps the version to 4.11.0, a minor release because this only adds functionality. The release also includes the unreleased OpenCV 4.14 wrappers from #103.
🤖 Generated with Claude Code