On 08/01/2018 12:18 PM, Tom de Vries wrote: > I think we need to add and handle: > ... > CUDA_ONE_CALL_MAYBE_NULL (cuOccupancyMaxPotentialBlockSize) > ... >
I realized that the patch I posted introducing CUDA_ONE_CALL_MAYBE_NULL was incomplete, and needed to use the weak attribute in case of linking against a concrete libcuda.so. So, I've now committed a patch implementing just CUDA_ONE_CALL_MAYBE_NULL: "[libgomp, nvptx] Handle CUDA_ONE_CALL_MAYBE_NULL" @ https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00447.html . You can use "CUDA_CALL_EXISTS (cuOccupancyMaxPotentialBlockSize)" to test for existence of the function in the cuda driver API. > The patch doesn't build in a setup with > --enable-offload-targets=nvptx-none and without cuda, that enables usage > of plugin/cuda/cuda.h: > ... > /data/offload-nvptx/src/libgomp/plugin/plugin-nvptx.c:98:16: error: > ‘cuOccupancyMaxPotentialBlockSize’ undeclared here (not in a function); > did you mean ‘cuOccupancyMaxPotentialBlockSizeWithFlags’? > CUDA_ONE_CALL (cuOccupancyMaxPotentialBlockSize) \ > ... > I've committed a patch "[libgomp, nvptx, --without-cuda-driver] Don't use system cuda driver" @ https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00348.html . Using --without-cuda-driver should make it easy to build using the dlopen interface without having to de-install the system libcuda.so. Thanks, - Tom
