WIP: Switch to use new Python bindings from cuda-python/cuda-bindings

[leofang]

Part of #130.

Note: Currently to try this PR it requires building cuda-python/cuda-bindings from source:
https://github.com/NVIDIA/cuda-python/tree/main/cuda_bindings

• Drop the old, CPython API-based nvJitLink bindings, in favor of the new one from CUDA Python
  • Support dynamic linking, no more rebuilding bindings for each CUDA minor release
    • nvidia-nvjitlink-cu12 wheel on Linux is not yet supported (on Windows it works), see Add nvjitlink bindings NVIDIA/cuda-python#98
  • Support Windows
  • pynvjitlink becomes a pure Python package
• All tests in pynvjitlink/tests/test_pynvjitlink.py passed except one (see comment below)
  • I need someone to help take a look

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[leofang]

This is the failing test:

$ pytest test_pynvjitlink.py  --maxfail=3
============================================================= test session starts =============================================================
platform linux -- Python 3.12.5, pytest-8.3.3, pluggy-1.5.0
rootdir: /local/home/leof/dev/pynvjitlink
configfile: pyproject.toml
collected 20 items                                                                                                                            

test_pynvjitlink.py ............F.......                                                                                                [100%]

================================================================== FAILURES ===================================================================
_____________________________________________________________ test_get_error_log ______________________________________________________________

undefined_extern_cubin = ('undefined_extern.cubin', b'\x7fELF\x02\x01\x013\x07\x00\x00\x00\x00\x00\x00\x00\x01\x00\xbe\x00~\x00\x00\x00\x00\x00...0\x00\x00\x00\x00\x00\x03\x00\x00\x00\x07\x00\x00\x18\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
gpu_arch_flag = '-arch=sm_89'

    def test_get_error_log(undefined_extern_cubin, gpu_arch_flag):
        handle = _nvjitlinklib.create(gpu_arch_flag)
        filename, data = undefined_extern_cubin
        input_type = InputType.CUBIN.value
        _nvjitlinklib.add_data(handle, input_type, data, filename)
        with pytest.raises(_nvjitlinklib.nvJitLinkError):
            # FIXME: For some reason this API would leak the error log to stderr
            _nvjitlinklib.complete(handle)
        error_log = _nvjitlinklib.get_error_log(handle)
        _nvjitlinklib.destroy(handle)
>       assert (
            "Undefined reference to '_Z5undefff' "
            "in 'undefined_extern.cubin'" in error_log
        ), f"{error_log=}"
E       AssertionError: error_log='ERROR 9: finish\n\x00'
E       assert "Undefined reference to '_Z5undefff' in 'undefined_extern.cubin'" in 'ERROR 9: finish\n\x00'

test_pynvjitlink.py:81: AssertionError
------------------------------------------------------------ Captured stderr call -------------------------------------------------------------
error   : Undefined reference to '_Z5undefff' in '�����'
=========================================================== short test summary info ===========================================================
FAILED test_pynvjitlink.py::test_get_error_log - AssertionError: error_log='ERROR 9: finish\n\x00'
======================================================== 1 failed, 19 passed in 0.57s =========================================================

[leofang]

If we don't capture the exception raised by _nvjitlinklib.complete(handle), I do see the expected error log (no weird unicode mess) showing up in stderr, which is weird/unexpected.

[gmarkall]

This might be a regression in the version of nvJitLink used. Is that on your local system? What is the nvJitLink version?

[leofang]

Given that this PR turns pynvjitlink into a pure Python package (I think!), I don't really know what to put here, given that I've never used CMake to package a pure Python project... 😆

[gmarkall]

I don't think it makes sense to involve CMake for a pure Python package. Probably only a pyproject.toml would be necessary.

[bdice]

Yes, we would need to rearchitect the build systems and CI scripts to account for having only a single build of a pure Python package.

[leofang]

For some reason I had to set the env var NUMBA_CUDA_USE_NVIDIA_BINDING=1 to run the tests, otherwise I hit weird type errors when Numba tried to load the cubin etc using the Driver APIs (through ctypes).

[gmarkall]

If that's occurring, I think this PR is likely to be changing the API of pynvjitlink such that the type of a returned cubin is different. I haven't been able to guess exactly what might be happening from the code, so will have to try it locally (or if you have the type error handy, feel free to share it).

[gmarkall]

/ok to test

[bdice]

@gmarkall @leofang If you'd like a hand with the repackaging to make pynvjitlink a pure Python package, let me know. I can help with some pieces of this.

[warsawnv]

Just a couple more drive-by observations. Feel free to ignore.

[gmarkall]

If test binaries need to be built for Windows, I added a script to numba-cuda that builds them - it might be useful to copy across to this PR when Windows support is added / tested: https://github.com/NVIDIA/numba-cuda/blob/main/numba_cuda/numba/cuda/tests/test_binary_generation/build.bat

[leofang]

This is no longer needed now that NVIDIA/numba-cuda#124 and NVIDIA/numba-cuda#133 are resolved.