USM availability

[Iokiae]

Hey, I have just gotten into GPGPU and decided to try out SYCL and thus came about to this project (yesterday it was called something different?). So I managed to compile the compiler and build a test project, but each time I start I get a warning that my GPU (Radeon 6800XT gfx1030) does not support USM. If that is true, how am I able to allocate memory using malloc_shared() as the example I am using works just fine using it. Are there workarounds when it comes to shared pointers?

I know this is not support forum for newbie beginner question, but I don't know where else to go (any tips regarding that would be more than welcome).

Thanks everyone in advance :D

[illuhad]

Hi!

regarding the project name, see #1147. In short, this renaming has been in the making for a long time and has been discussed for just as long.

The error you are seeing is emitted from the OpenCL backend when it checks which devices are available. The AMD OpenCL drivers do not support USM, and so you get this warning.

However, the same device may occasionally be available through multiple paths in the AdaptiveCpp runtime. We have both a vendor-independent OpenCL backend as well as a native HIP/ROCm backend for AMD GPUs. If you have built AdaptiveCpp with both backends enabled, and have the AMD OpenCL driver installed, you will see the GPU twice in AdaptiveCpp: Once from OpenCL, and once from HIP/ROCm. The latter supports USM just fine.

My guess is that you use the GPU from the HIP backend, and so all your USM code samples work. In this case you can ignore the warning. If you want you can use the environment variable HIPSYCL_VISIBILITY_MASK to blacklist the OpenCL backend to ensure that the GPU you get never comes from there. For example, HIPSYCL_VISIBILITY_MASK="omp;hip" will load only the OpenMP backend for the CPU and the HIP backend for your AMD GPU.

Note that shared allocations for AMD hardware often deliver massively subpar performance unless the GPU is configured in a special way. This is because AMD's driver stack really is behind the competition when it comes to support for shared allocations. This stackoverflow post discusses the issue in detail: https://stackoverflow.com/questions/76700305/4000-performance-decrease-in-sycl-when-using-unified-shared-memory-instead-of-d

[Iokiae]

Thank you very much, I have been struggling with this. I wish I could contribute also but I am not well versed in HIP or OpenCL or CUDA. Are there any other way to support the project like donations etc.? I didn't find anything on the homepage regarding this.

[illuhad]

We currently don't accept donations. The project is currently mainly funded through a German public research university (Heidelberg University) and that makes accepting donations difficult. I'm sure there's other ways for you to contribute, even if you are not an expert in the underlying technologies - documentation, refactoring due to the name change etc :-) EDIT: Or packaging for inclusion in Linux distros, that could be huge for the project!

[Iokiae]

Sadly time is something I lack a lot, but maybe handling packaging on AUR I could do. I see that the current version uses even the old old name hipSYCL.