If sycl-ls does not list the expected devices within the system:

1. Check that there is a compatible version of the CUDA® or ROCm™ SDK installed on the system (for CUDA or HIP plugins respectively), as well as the compatible drivers.

2. Check that nvidia-smi or rocm-smi can correctly identify the devices.

3. Check that the plugins are correctly loaded. This can be done by setting the environment variable SYCL_PI_TRACE to 1 and running sycl-ls again. For example:

   SYCL_PI_TRACE=1 sycl-ls
   
   

   You should see output similar to the following:

   SYCL_PI_TRACE[basic]: Plugin found and successfully loaded: libpi_opencl.so [ PluginVersion: 11.15.1 ]
   SYCL_PI_TRACE[basic]: Plugin found and successfully loaded: libpi_level_zero.so [ PluginVersion: 11.15.1 ]
   SYCL_PI_TRACE[basic]: Plugin found and successfully loaded: libpi_cuda.so [ PluginVersion: 11.15.1 ]
   [cuda:gpu][cuda:0] NVIDIA CUDA BACKEND, NVIDIA A100-PCIE-40GB 8.0 [CUDA 12.5]
   
   

   If the plugin you’ve installed doesn’t show up in the sycl-ls output, you can run it again with SYCL_PI_TRACE this time set to -1 to see more details of the error:

   SYCL_PI_TRACE=-1 sycl-ls
   
   

   Within the output, which can be quite large, you may see errors like the following:

   SYCL_PI_TRACE[-1]: dlopen(/opt/intel/oneapi/compiler/2024.2.1/linux/lib/libpi_hip.so) failed with <libamdhip64.so.4: cannot open shared object file: No such file or directory>
   SYCL_PI_TRACE[all]: Check if plugin is present. Failed to load plugin: libpi_hip.so

   • The CUDA plugin requires libcuda.so and libcupti.so from the CUDA SDK.

   • The HIP plugin requires libamdhip64.so from ROCm.

   Double-check your CUDA or ROCm installation and make sure that the environment is set up properly i.e. LD_LIBRARY_PATH points to the correct locations to find the above libraries.

4. Check that there isn’t any device filtering environment variable set such as ONEAPI_DEVICE_SELECTOR (note that sycl-ls will warn if this one is set), or SYCL_DEVICE_ALLOWLIST.

5. Check permissions. On POSIX access to accelerator devices is typically gated on being a member of the proper groups. For example, on Ubuntu Linux GPU access may require membership of the video and render groups, but this can vary depending on your configuration.

This may be caused by a number of things.

1. There is currently no support for std::complex in DPC++. Please use sycl::complex instead.

1. Some C++ standard library math functionality declared in <cmath> (such as std::cos, logf, sinf``) is not supported in kernel code for the AMDGPU backend of DPC++. Please use the equivalent sycl namespaced versions instead.

   See Install oneAPI for AMD GPUs for more information.

Consider code that uses the kernel attribute reqd_sub_group_size to set a specific sub-group size that is then ported to a different platform or executed on a different architecture to the one it was originally written for. In such a case if the requested sub-group size is not supported by the platform/architecture then a runtime error will be thrown:

Sub-group size x is not supported on the device

On the CUDA platform only a single sub-group size is supported, hence only a warning is given:

CUDA requires sub_group size 32

and the runtime will use the sub-group size of 32 instead of the requested sub-group size. The reqd_sub_group_size kernel attribute is designed for platforms/architectures that support multiple sub-group sizes. Note that some SYCL code is not portable across different sub-group sizes. For example, the result of the sub-group collective reduce_over_group will depend on the sub-group size. Users that want to write code that is portable across platforms/architectures which use different sub-group sizes should either:

• Write code in a portable way such that the result does not depend on sub-group size.

• sub-group size sensitive parts of the code should have different versions for different platforms/architectures to take account of different sub-group sizes.