Use cuda.bindings and cuda.core for Linker

[brandon-b-miller]

WIP
xref #129

[leofang]

Thanks, @brandon-b-miller. Remember our goal is to drop every Linker subclasses inside Numba, in favor of cuda.core.Linker. The current PR is not what we want. Also note that to help pynvjitlink to phase out, we already have rapidsai/pynvjitlink#111 which is essentially what this PR does today.

[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.

[isVoid]

Since we switched to context independent loading API, the CUDADispatcher.bind method should probably be renamed since it no longer binds context via calling the get_cufunc function.

[brandon-b-miller]

/ok to test

[brandon-b-miller]

@gmarkall @leofang numba-cuda contains nvjitlink tests, should we maintain support for these as part of this PR or drop them in favor of testing in upstream cuda-python?

[gmarkall]

@gmarkall @leofang numba-cuda contains nvjitlink tests, should we maintain support for these as part of this PR or drop them in favor of testing in upstream cuda-python?

I think we need to maintain the tests that test Numba-CUDA's interaction with the linker, like the TestLinkerUsage class and the test_*_with_linkable_code (tests with names like that). I don't think we need to keep the tests that purely test the PyNvJitLinker API like the ones that test passing different flags etc. to it.

[gmarkall]

Also, I think we can probably delete the PyNvJitLinker class in this PR as well - is there any reason to keep it around?

I'm comfortable with:

• Using cuda.core.Linker when the user asks for pynvjitlink or the NVIDIA bindings, and
• Using the ctypes linker otherwise

which is what this PR seems to offer. (correct me if I've read it wrong 🙂)

[brandon-b-miller]

Also, I think we can probably delete the PyNvJitLinker class in this PR as well - is there any reason to keep it around?

I'm comfortable with:

• Using cuda.core.Linker when the user asks for pynvjitlink or the NVIDIA bindings, and
• Using the ctypes linker otherwise

which is what this PR seems to offer. (correct me if I've read it wrong 🙂)

Correct, this is the outcome I am aiming for.

[brandon-b-miller]

@gmarkall on second thought, we might need to leave the MVCLinker in in some capacity as long as we're supporting cuda 11. I don't think that cuda-python supports the functionality that cubinlinker enables.

[gmarkall]

@brandon-b-miller Sorry, yes - I had that in mind but didn't write it down.

[brandon-b-miller]

@brandon-b-miller Sorry, yes - I had that in mind but didn't write it down.

Ok, just to have it written down somewhere, after this PR we will:

For cuda 11, maintain the current way of configuring which bindings to use:

• Default ctypes bindings, optional cuda-python bindings with NUMBA_CUDA_USE_NVIDIA_BINDING=1, optional MVCLinker with NUMBA_CUDA_ENABLE_MINOR_VERSION_COMPATIBILITY=1.

for cuda 12, we will have:

• Default ctypes bindings, optional cuda-python bindings with NUMBA_CUDA_USE_NVIDIA_BINDING=1
• Use of pynvjitlink through cuda-python if NUMBA_CUDA_ENBALE_PYNVJITLINK=1

This will leave us with 3 linkers:

• The ctypes linker which is used by default regardless of cuda version
• the mvc linker which is used in a cuda 11 environment when mvc is required, regardless of what binding is being used
• the new linker which is used in a cuda 12 enviornment either the cuda-python bindings or pynvjitlink is enabled

[gmarkall]

Thanks for the summary! To look a little further ahead, we want to end up with only one linker, which is the new linker. This would be achieved by deprecating / removing the other linkers as soon as appropriate:

• MVCLinker can be removed as soon as CUDA 11 support is dropped.
• The ctypes linker can be deprecated and removed whenever we can have a hard dependency on cuda.core and had tested the new linker in use for a bit to shake out any issues.

Are you in alignment with the above plan @brandon-b-miller ?

[brandon-b-miller]

Thanks for the summary! To look a little further ahead, we want to end up with only one linker, which is the new linker. This would be achieved by deprecating / removing the other linkers as soon as appropriate:

• MVCLinker can be removed as soon as CUDA 11 support is dropped.
• The ctypes linker can be deprecated and removed whenever we can have a hard dependency on cuda.core and had tested the new linker in use for a bit to shake out any issues.

Are you in alignment with the above plan @brandon-b-miller ?

Yup this sounds good to me.

[brandon-b-miller]

There's a few cases in this class where I'm finding I have to do something like this. We discussed wanting to avoid having an ObjectCode constructor for every type of possible input, but it seems like numba requires the ability to assemble the eventual inputs to the link from a pretty broad variety of sources.

[gmarkall]

It seems like we need an API to be able to construct ObjectCode instances from inputs of arbitrary kinds - archives, cubins, LTOIR, fatbins, etc.. It seems like the existing interface is aimed at providing something relatively safe, but doesn't allow for the lower-level / fine-grained control we need here to set up and complete a link.

Is that understanding correct?

[brandon-b-miller]

This is what I've arrived at doing, @leofang and I have had a few conversations about how this capability would fit into the broader goals of the cuda-python API, I'd be curious his thoughts.

[gmarkall]

/ok to test