Intel Proposes Adding Full SYCL Programming Model Support To Upstream LLVM

[phoronix]

Phoronix: Intel Proposes Adding Full SYCL Programming Model Support To Upstream LLVM

Intel engineers are proposing that full support for the SYCL programming model be added to upstream LLVM. This is part of their broader oneAPI effort and embracing Khronos' SYCL standard for single-source C++ heterogeneous programming from CPUs to GPUs, FPGAs, and other accelerators...

https://www.phoronix.com/news/Intel-Full-SYCL-Upstream-LLVM

[9Strike]

Nice!

[oleid]

Great that this gets more traction!

What's the current state of Sycl? Did it get any new backends these days? The last time I checked it was OpenCL only.
Would it work natively on CUDA or ROCm? How about vulkan compute? I figure there are mobile devices out there without OpenCL support, but vulkan compute.

[ms178]

Deja-vu, wasn't HSA solving the same underlying problems (in a different way)? It is painfully slow to see progress on that technological front, as HSA was talked about in 2012 already and here we are in 2023.

[RonanKeryell]

Great that this gets more traction!

What's the current state of Sycl? Did it get any new backends these days? The last time I checked it was OpenCL only.
Would it work natively on CUDA or ROCm? How about vulkan compute? I figure there are mobile devices out there without OpenCL support, but vulkan compute.

At the last SYCLcon https://www.iwocl.org/iwocl-2023/conference-program/ there was a "SYCL State of the Union" presentation giving some hints, even if it is 6 month old already.

https://www.youtube.com/watch?v=StqDWKzhk7A&list=PL46sP9LM8Gszc1ABV66YneXr7j8mT7Vz_&index=2

https://www.iwocl.org/wp-content/uploads/iwocl-2023-Michael-Wong-SYCL-SOU.pdf

There are quite many targets nowadays.
There was at least a research prototype a few years ago targeting Vulkan: Sylkan.
Vulkan SC is also one of the envisioned target of SYCL SC, the version of the SYCL standard targeting safety-critical systems.

[RonanKeryell]

Deja-vu, wasn't HSA solving the same underlying problems (in a different way)? It is painfully slow to see progress on that technological front, as HSA was talked about in 2012 already and here we are in 2023.

By "in a different way" do you mean hardware (HSA) versus software (SYCL)?
SYCL started around 2011 too, so, yes this is slow. :-(

[ms178]

By "in a different way" do you mean hardware (HSA) versus software (SYCL)?
SYCL started around 2011 too, so, yes this is slow. :-(

If I remember correctly you are deeply involved in the development of these standards. I am just an interested bystander from the peanut gallery.

Actually, I meant from a software-implementation perspective for both providing a programming model for single-source C++ heterogeneous programming. On the software side, HSA had HSAIL and a Finalizer to target the underlying hardware - SYCL uses a slightly different approach with a bit more abstractions due to several API layers involved if I am not mistaken.

Concerning the hardware side, honestly I don't remember too much specifics, but I assume there are also some hardware / platform capabilities needed for proper SYCL support, right? At least to get good performance out of each device/accelerator working together without too much API overhead? In the past, AMD made a point in benchmarking HSA vs OpenCL for faster Kernel execution on the same hardware. But I cannot tell if the platform capabilities and APIs evolved so far to allow this more performant today.

I hope it won't take another decade to see the fruits of your and your colleague's work.

[andrei_me]

I remember SYCL started to grow when they replaced/updated to SPIR-V as IR, all the parts/standards started to fit nicely together since then

[RonanKeryell]

I remember SYCL started to grow when they replaced/updated to SPIR-V as IR, all the parts/standards started to fit nicely together since then

While having a standard portable IR like SPIR-V definitely helps, there is nothing in SYCL that requires it. There are several compiler flows which use directly LLVM IR or MLIR for example.

[RonanKeryell]

Actually, I meant from a software-implementation perspective for both providing a programming model for single-source C++ heterogeneous programming. On the software side, HSA had HSAIL and a Finalizer to target the underlying hardware - SYCL uses a slightly different approach with a bit more abstractions due to several API layers involved if I am not mistaken.

Concerning the hardware side, honestly I don't remember too much specifics, but I assume there are also some hardware / platform capabilities needed for proper SYCL support, right? At least to get good performance out of each device/accelerator working together without too much API overhead? In the past, AMD made a point in benchmarking HSA vs OpenCL for faster Kernel execution on the same hardware. But I cannot tell if the platform capabilities and APIs evolved so far to allow this more performant today.

I hope it won't take another decade to see the fruits of your and your colleague's work.

Yes you are right there are various levels where the problem can be addressed in the full hardware/software stack.
I think the problem with HSA is that it was a hardware solution designed by hardware people, with a very prescriptive approach for the hardware implementors, an IR not designed by compiler people, etc.
At the end HSA did not solve the other problems beyond that everyone has to implement HSA or it does not work. What to do in real life with different accelerators at the same time?
So, some level of cross-API low-level dispatch is required anyway. HSA is one of the API and is actually used under the hood by the 2 major SYCL implementations when targeting AMD ROCm/HIP.

Concerning the speed of deployment of a given technology by my company (AMD) or others, this is definitely quite above my pay-grade. :-)