[FEA]: Add CUDA driver version query to cuda.pathfinder (private API)#1953
[FEA]: Add CUDA driver version query to cuda.pathfinder (private API)#1953rwgk wants to merge 14 commits intoNVIDIA:mainfrom
cuda.pathfinder (private API)#1953Conversation
Break out CUDA driver version querying into a standalone internal utility so it can be reused independently from compatibility checks, and cover the ctypes loader paths with focused tests. Made-with: Cursor
Treat the Windows WinDLL path as the normal runtime case and keep the focused tests aligned with the stricter driver-loader invariants. Made-with: Cursor
Wrap the encoded cuDriverGetVersion() result in a DriverVersion dataclass so callers can use major and minor fields directly while retaining a low-level integer helper for loader-focused tests. Made-with: Cursor
Cover query_driver_version() alongside the driver library loading tests and reuse the existing strictness mode so host-specific failures still surface cleanly in all_must_work mode. Made-with: Cursor
Drop the non-Windows loader mock now that a real driver-version test covers the Linux success path, while keeping the Windows branch and failure-path unit coverage. Made-with: Cursor
Use DriverCudaVersion for clearer pairing with the planned release-version type while keeping the existing driver info API behavior unchanged. Made-with: Cursor
Query nvmlSystemGetDriverVersion() through pathfinder's driver library loading path and add a minimal real test so the implementation is preserved as a future reference. Made-with: Cursor
Step back from the exploratory NVML-based release-version query for now because it adds non-trivial complexity and a new dependency surface without a current pathfinder need, while keeping the reference implementation in history if we need it later. Made-with: Cursor
Document that DriverCudaVersion matches the CUDA Version shown by nvidia-smi rather than the graphics driver release, so the dataclass name reads clearly in context. Made-with: Cursor
Expose DriverCudaVersion, QueryDriverCudaVersionError, and query_driver_cuda_version publicly, and align the internal naming, caching, docs, and test coverage around the CUDA-specific driver version query. Made-with: Cursor
Protect the new top-level driver-info re-exports so internal-only test coverage does not miss a broken `cuda.pathfinder` plumbing layer. Made-with: Cursor
rwgk
added
P0
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
/ok to test |
|
There was a problem hiding this comment.
I am confused. Why wouldn't people just use cuda.bindings or cuda.core for this purpose? Why are we duplicating the functionality in cuda-pathfinder?
There was a problem hiding this comment.
I am confused. Why wouldn't people just use cuda.bindings or cuda.core for this purpose? Why are we duplicating the functionality in cuda-pathfinder?
cuda-bindings depends on cuda-pathfinder. We'd get a dependency cycle:
Note that I need this functionality for #1038 ("scoped" is not the main theme anymore, "compatibility checks" is, but I didn't want to change the title of the issue).
Another aspect: cuda-pathfinder is meant to require pure Python only (no compilation). This ties in directly with: cuda-pathfinder is meant to be usable as a build-time dependency (e.g. build hooks).
Luckily, the "duplication" is just a handful of ctypes-based lines of code.
There was a problem hiding this comment.
Dropping a quick note based on concerns I raised during team sync.
We definitely do not want to introduce any dependency cycle. However, we also don't want to expand the API surface unnecessarily. It is confusing to have every level of the CUDA Python stack (pathfinder, bindings, core, ...) expose the same API.
As far as #1038 (and general pathfinder needs) is concerned, the driver version query is a mean to the end that can be hidden as implementation detail.
There was a problem hiding this comment.
Done: commit a450104
I removed the public re-exports from cuda.pathfinder and kept the driver-version query as an internal implementation detail.
To note the tradeoff I see: this does leave a potentially useful capability unavailable to users who may want to stay with cuda.pathfinder alone and avoid a cuda-bindings dependency, especially in lighter-weight or build-time contexts where cuda.pathfinder is already usable from build_hooks.py. A concern I still have is that, if we do not offer a small supported pathfinder-level entry point here, similar needs may become more likely to get handled with quick ad-hoc solutions in downstream code, which can unintentionally create duplication and tech debt. I’m fine with taking the narrower route here for now, but wanted to capture that consideration explicitly.
Stop exposing the new driver info helper through cuda.pathfinder while keeping the internal implementation and internal test coverage in place. Made-with: Cursor
|
/ok to test |
|
|
rwgk
changed the title
cuda.pathfindercuda.pathfinder (private API)
2 participants
xref: #1038, #1936
cuda.pathfinder._utils.driver_infohelper backed bycuDriverGetVersion()socuda.pathfindercan query the CUDA-facing driver versionDriverCudaVersion,QueryDriverCudaVersionError, and cachedquery_driver_cuda_version(), with naming and docstrings that make it explicit this matchesnvidia-smi'sCUDA Versionre-export the new API fromcuda.pathfinder, document it incuda_pathfinder/docs/source/api.rst, and add focused unit, real-driver, and public-import regression testsAll new
INFOlines are identical across all CI test logs:https://github.com/NVIDIA/cuda-python/actions/runs/24639785901/attempts/1?pr=1953