Use pathfinder for dynamic libraries
#308
Conversation
|
Auto-sync is disabled for ready for review pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
|
||
|
|
||
| def _get_source_variable(lib, static=False): | ||
| # remove? only used in test() |
There was a problem hiding this comment.
Should we remove this function and test() below? cuda_paths also supports saying what the source of the loaded library is, such as if it's a wheel vs conda lib etc. Path finder treats this as an implementation detail.
We could always change it to just report the path without the source but its possible this function has proliferated a bit and is used for debugging out in the wild.
There was a problem hiding this comment.
Path finder treats this as an implementation detail.
A hint could be added to the LoadedDL type if that's useful. Do you think it will be?
LoadedDL reliably includes the absolute path, even if the library was loaded outside of path finder. The path is more conclusive and usually it's very obvious if it's from a wheel, conda, or full CTK installation.
There was a problem hiding this comment.
Thanks, that's helpful context. I think the best solution then would be one that maintains the current function, but decodes what the library source is on the numba side. I can take a whack at this and see how it looks.
There was a problem hiding this comment.
If it's possible to keep the test() functionality I'd prefer that - it has been quite important for debugging in the past. For a lot of misconfigurations on peoples' systems, Numba-CUDA has not been the root cause of an issue but it is often the first place where a problem manifests, so it's been invaluable for showing people what the issue is and demonstrating that it's not just that "Numba-CUDA is broken". It's OK if the format of the output changes, but whatever information we can provide here from the CUDA pathfinder that provides parity with existing functionality will be helpful.
Also note that Numba will attempt to call it when producing sysinfo, so if it is removed entirely then it'll break numba sysinfo's (running python -m numba -s or numba -s) ability to show info about CUDA: https://github.com/numba/numba/blob/0c633b896526b039171c0f800df70320e1c61a53/numba/misc/numba_sysinfo.py#L381
There was a problem hiding this comment.
but whatever information we can provide here from the CUDA pathfinder that provides parity with existing functionality will be helpful.
Ok, tx, I'll work on adding that in.
| configuration. | ||
| """ | ||
|
|
||
| # CUDA headers |
There was a problem hiding this comment.
These aren't a library but are still needed by numba, is this something pathfinder will support?
There was a problem hiding this comment.
+1 for this feature in pathfinder
|
@rwgk could you help review? (I can't add you as a reviewer for some reason) |
rwgk
left a comment
rwgk
left a comment
There was a problem hiding this comment.
I don't have a lot of numba-cuda specific context, but what I see in this PR looks good to me.
| configuration. | ||
| """ | ||
|
|
||
| # CUDA headers |
|
|
||
|
|
||
| def _get_source_variable(lib, static=False): | ||
| # remove? only used in test() |
There was a problem hiding this comment.
Path finder treats this as an implementation detail.
A hint could be added to the LoadedDL type if that's useful. Do you think it will be?
LoadedDL reliably includes the absolute path, even if the library was loaded outside of path finder. The path is more conclusive and usually it's very obvious if it's from a wheel, conda, or full CTK installation.
| from numba.cuda.cudadrv.driver import locate_driver_and_loader, load_driver | ||
| from numba.cuda.cudadrv.error import CudaSupportError | ||
| from numba.core import config | ||
| from cuda.bindings import path_finder |
There was a problem hiding this comment.
@rwgk wouldn't this break once we make pathfinder a standalone module? (NVIDIA/cuda-python#723)
There was a problem hiding this comment.
I was thinking not, because my intention is to keep the backward compatibility code for a cuda_bindings release or two.
I just saw @kkraus14 asked about adding a deprecation warning in that code (on NVIDIA/cuda-python#723): I'd don't think there is a rush to get rid of the few lines of backward compatibility code, therefore I'd lean towards making it easy for the world, by staging: one cuda_bindings release without deprecation warning, the next one or two cuda_bindings releases with warning, then remove the backward compatibility code.
(This is very similar to how features are deprecated in CPython.)
There was a problem hiding this comment.
I'm good with the approach of phasing in the deprecation.
|
|
|
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 |
brandon-b-miller
changed the title
cuda_paths in favor of using cuda.bindings.path_finder to find CUDA componentspathfinder for dynamic libraries
|
/ok to test |
|
/ok to test |
|
/ok to test |
|
/ok to test |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
/ok to test |
|
/ok to test |
|
/ok to test |
|
/ok to test |
|
/ok to test |
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
|
/ok to test |
|
/ok to test |
- Add Python 3.14 to the wheel publishing matrix (NVIDIA#750) - feat: swap out internal device array usage with `StridedMemoryView` (NVIDIA#703) - Fix max block size computation in `forall` (NVIDIA#744) - Fix prologue debug line info pointing to decorator instead of def line (NVIDIA#746) - Fix kernel return type in DISubroutineType debug metadata (NVIDIA#745) - Fix missing line info in Jupyter notebooks (NVIDIA#742) - Fix: Pass correct flags to linker when debugging in the presence of LTOIR code (NVIDIA#698) - chore(deps): add cuda-pathfinder to pixi deps (NVIDIA#741) - fix: enable flake8-bugbear lints and fix found problems (NVIDIA#708) - fix: Fix race condition in CUDA Simulator (NVIDIA#690) - ci: run tests in parallel (NVIDIA#740) - feat: users can pass `shared_memory_carveout` to @cuda.jit (NVIDIA#642) - Fix compatibility with NumPy 2.4: np.trapz and np.in1d removed (NVIDIA#739) - Pass the -numba-debug flag to libnvvm (NVIDIA#681) - ci: remove rapids containers from conda ci (NVIDIA#737) - Use `pathfinder` for dynamic libraries (NVIDIA#308) - CI: Add CUDA 13.1 testing support (NVIDIA#705) - Adding `pixi run test` and `pixi run test-par` support (NVIDIA#724) - Disable per-PR nvmath tests + follow same test practice (NVIDIA#723) - chore(deps): regenerate pixi lockfile (NVIDIA#722) - Fix DISubprogram line number to point to function definition line (NVIDIA#695) - revert: chore(dev): build pixi using rattler (NVIDIA#713) (NVIDIA#719) - [feat] Initial version of the Numba CUDA GDB pretty-printer (NVIDIA#692) - chore(dev): build pixi using rattler (NVIDIA#713) - build(deps): bump the actions-monthly group across 1 directory with 8 updates (NVIDIA#704)
- Add Python 3.14 to the wheel publishing matrix (#750) - feat: swap out internal device array usage with `StridedMemoryView` (#703) - Fix max block size computation in `forall` (#744) - Fix prologue debug line info pointing to decorator instead of def line (#746) - Fix kernel return type in DISubroutineType debug metadata (#745) - Fix missing line info in Jupyter notebooks (#742) - Fix: Pass correct flags to linker when debugging in the presence of LTOIR code (#698) - chore(deps): add cuda-pathfinder to pixi deps (#741) - fix: enable flake8-bugbear lints and fix found problems (#708) - fix: Fix race condition in CUDA Simulator (#690) - ci: run tests in parallel (#740) - feat: users can pass `shared_memory_carveout` to @cuda.jit (#642) - Fix compatibility with NumPy 2.4: np.trapz and np.in1d removed (#739) - Pass the -numba-debug flag to libnvvm (#681) - ci: remove rapids containers from conda ci (#737) - Use `pathfinder` for dynamic libraries (#308) - CI: Add CUDA 13.1 testing support (#705) - Adding `pixi run test` and `pixi run test-par` support (#724) - Disable per-PR nvmath tests + follow same test practice (#723) - chore(deps): regenerate pixi lockfile (#722) - Fix DISubprogram line number to point to function definition line (#695) - revert: chore(dev): build pixi using rattler (#713) (#719) - [feat] Initial version of the Numba CUDA GDB pretty-printer (#692) - chore(dev): build pixi using rattler (#713) - build(deps): bump the actions-monthly group across 1 directory with 8 updates (#704) <!-- Thank you for contributing to numba-cuda :) Here are some guidelines to help the review process go smoothly. 1. Please write a description in this text box of the changes that are being made. 2. Please ensure that you have written units tests for the changes made/features added. 3. If you are closing an issue please use one of the automatic closing words as noted here: https://help.github.com/articles/closing-issues-using-keywords/ 4. If your pull request is not ready for review but you want to make use of the continuous integration testing facilities please label it with `[WIP]`. 5. If your pull request is ready to be reviewed without requiring additional work on top of it, then remove the `[WIP]` label (if present) and replace it with `[REVIEW]`. If assistance is required to complete the functionality, for example when the C/C++ code of a feature is complete but Python bindings are still required, then add the label `[HELP-REQ]` so that others can triage and assist. The additional changes then can be implemented on top of the same PR. If the assistance is done by members of the rapidsAI team, then no additional actions are required by the creator of the original PR for this, otherwise the original author of the PR needs to give permission to the person(s) assisting to commit to their personal fork of the project. If that doesn't happen then a new PR based on the code of the original PR can be opened by the person assisting, which then will be the PR that will be merged. 6. Once all work has been done and review has taken place please do not add features or make changes out of the scope of those requested by the reviewer (doing this just add delays as already reviewed code ends up having to be re-reviewed/it is hard to tell what is new etc!). Further, please do not rebase your branch on main/force push/rewrite history, doing any of these causes the context of any comments made by reviewers to be lost. If conflicts occur against main they should be resolved by merging main into the branch used for making the pull request. Many thanks in advance for your cooperation! -->
7 participants
Towards #302
This PR switches to using
pathfinderto locatenvvmandnvrtcwithinnumba-cuda.