Is your feature request related to a problem? Please describe.
This stems from #1243.
MatX currently makes occasional use of the CUDA driver APIs directly. MatX can be compiled on a machine without an NVIDIA driver, using the driver stubs, but the driver library is DT_NEEDED on linux. This in turn prevents a library (or app) using MatX from being loaded on linux, on machines without an NVIDIA driver. On Windows, the issue is less severe since, at least in my very limited Windows knowledge, libraries are loaded lazily only when a symbol is requested.
Describe the solution you'd like
MatX should ideally always be loadable, even on machines without a driver. This allows e.g. an application using MatX to be started, then probing the driver availability to select the appropriate implementation. A test should verify this case.
Describe alternatives you've considered
An alternative I could think of is creating a thin shared library wrapper, only to be loaded conditionally at runtime. This is the usual approach in frameworks like, e.g., onnxruntime, it works as expected, but largely defies the purpose of having a header-only library. It also leads to concerns related to code protection in contexts where static linking is the norm.
Additional context
I am not very familiar with low-level CUDA driver APIs, even less so with MatX code, but some research reveals that driver calls can usually be replaced by CUDA-runtime calls. Such calls are largely equivalent, even if not identical, and ensure that the driver is only loaded if available through the CUDA runtime itself.
I prepared a tentative patch, leveraging to a large extent a LLM, in #1247. While I built and tested the code successfully on a local machine, please only take it as a possible starting point. I am using such patch in further tests I am doing with MatX.
Is your feature request related to a problem? Please describe.
This stems from #1243.
MatX currently makes occasional use of the CUDA driver APIs directly. MatX can be compiled on a machine without an NVIDIA driver, using the driver stubs, but the driver library is
DT_NEEDEDon linux. This in turn prevents a library (or app) using MatX from being loaded on linux, on machines without an NVIDIA driver. On Windows, the issue is less severe since, at least in my very limited Windows knowledge, libraries are loaded lazily only when a symbol is requested.Describe the solution you'd like
MatX should ideally always be loadable, even on machines without a driver. This allows e.g. an application using MatX to be started, then probing the driver availability to select the appropriate implementation. A test should verify this case.
Describe alternatives you've considered
An alternative I could think of is creating a thin shared library wrapper, only to be loaded conditionally at runtime. This is the usual approach in frameworks like, e.g., onnxruntime, it works as expected, but largely defies the purpose of having a header-only library. It also leads to concerns related to code protection in contexts where static linking is the norm.
Additional context
I am not very familiar with low-level CUDA driver APIs, even less so with MatX code, but some research reveals that driver calls can usually be replaced by CUDA-runtime calls. Such calls are largely equivalent, even if not identical, and ensure that the driver is only loaded if available through the CUDA runtime itself.
I prepared a tentative patch, leveraging to a large extent a LLM, in #1247. While I built and tested the code successfully on a local machine, please only take it as a possible starting point. I am using such patch in further tests I am doing with MatX.