Repository navigation
Re-work on Linker dispatching logic #712
Description
CUDA 12.0 is the first release where nvJitLink debuts. So far we have been operating under the assumption that nvJitLink is always available and can always generate a PTX (or CUBIN) that the driver can load. However, this assumption partially relies on another assumption that both nvJitLink and the driver are within the same major version 12.x.
By the time the next major release is out, there exists a possibility that the driver version (13.x) is newer than nvJitLink version (12.x). In this case, unless we need to link LTO IRs (which the driver cannot handle) we should prefer for the driver to handle the linking, instead of using nvJitLink. For linking LTO IRs, we must raise an exception.
We should also raise an exception if the user tries to link LTO IRs from different major versions. I believe it is not a supported use case. However, we currently do not have any introspection capability to check the LTO IR version.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
rparolin commentedon May 26, 2026
@isVoid I moved this issue to you to take a look at. Let me know if you have any questions.
cc: @leofang
isVoid commentedon May 26, 2026
Looking at @cpcloud 's PR 1911, the base solution there is sane. So I would plan to lift that PR to the most recent state as my first goal here. That PR should address the majority of this issue.
One improvement I can think of is the lack of real CI environment testing setup to confirm the pass/expected failure of the setup. The tests in the PR is largely "smoke tests" assuming that all version detectors under the hood works as expected.
isVoid commentedon May 26, 2026
As for this, it should be in a different PR. The current status isn't that bad. If you feed 13.0 LTOIR into 12.9 nvjitlink, an python exception is re-raised from nvjitlinkError.
We could provide more information on top of this to suggest that your nvjitlink version is 12.9 and the LTOIR is compiled from a 13.0 toolkit and prompt user to upgrade their nvjitlink version. An alternative is obviously preemptively check the version of the LTOIR and compare it with the toolchain in the environment before even launching nvjitlink. But I suspect it's probably not that much of a performance difference.