hipSYCL Becomes Open SYCL For Targeting All Major CPUs & GPUs

[phoronix]

Phoronix: hipSYCL Becomes Open SYCL For Targeting All Major CPUs & GPUs

The past few years there has been hipSYCL as an open-source project for not only taking SYCL codes to Radeon ROCm with HIP but also NVIDIA CUDA and other targets. The hipSYCL project has now decided to rename itself to Open SYCL to reflect its broader focus on supporting CPUs and GPUs from all major vendors and not being limited to just AMD's HIP interface...

https://www.phoronix.com/news/hipSYCL-Becomes-Open-SYCL

[Veto]

Can AMD be targeted via SPIR-V? (Just to have a Mesa based stack)

Also SYCL seems to be a good candidate for benchmarks

[illuhad]

Can AMD be targeted via SPIR-V? (Just to have a Mesa based stack)

Also SYCL seems to be a good candidate for benchmarks

Currently AMD cannot be targeted via SPIR-V because AMD OpenCL compute drivers do not support SPIR-V ingestion. That might change in the future with community projects such as rusticl. Vulkan uses a different SPIR-V dialect with additional restrictions compared to compute-focused APIs, so it also cannot be used to directly run with SPIR-V for SYCL.
Additionally, many applications in practice would want to integrate with optimized, vendor-supported libraries (e.g. for linear algebra, parallel primitives, FFTs, ...) making it often more desirable to integrate with vendor compute stacks for interoperability instead of third-party stacks like Mesa even if those are mature and performant. This is why Open SYCL has a unified code representation that is independent of SPIR-V that can be lowered at runtime to whatever vendor compute stacks want.

[Eirikr1848]

runtime.png

OK let's look at how OpenSYCL (Formerly HIPSYCL) fits in to this SYCL mess. (from the OpenCL git linked above)
Why are DPC++ and OpenSYCL changes not merged higher in the tree? This seems like an awfully lot of separate efforts to distribute workloads.
Why don't we have the primary SYCL runtime library distributing to the various "branches" of SYCL, then to the runtime plugins, and backends from there?

Essentially: Trying to get a client's laptop set up is difficult enough! Specs: (Intel 9th Gen Core CPU + Intel 9.5Gen HD 600-series iGPU + RTX 2000 dGPU + Vega Frontier eGPU + 1x Intel Movidius Neural Compute Stick + 3x Intel Neural Compute Stick 2 + 1x m.2 PCIe Intel Movidius Myriad X VPU

OpenVINO/OpenCV don't even slot into the SYCL stack, even on the OneAPI side! So for 9 devices, 5.5 different architectures, this is an SDK and dev environment variable nightmare.

1) Intel Needs: To add VPUs to stack (unified with Intel)
2) Intel Needs: To ad RT cores to stack (unified with Intel)
3) AMD Needs: To Integrate Xilinix to stack (unified with Intel)

With AMD and Intel both having hefty open source driver stacks, and both being the underdogs, it seems they both could have a better interop strat in place - they only have "up" to go in terms of datacenter and consumer compute add-in board sales. Additionally, it seems advantageous for them to add their Movidius and Xilinx stacks to SYCL.

Additionally: syscl-gtx seems like it would be super critical as a fallback! This would work well for the Arm Mali, Broadcom, and other OpenCL efforts along with rusticl to have true cohesion even if other device types aren't supported.

[illuhad]

OK let's look at how OpenSYCL (Formerly HIPSYCL) fits in to this SYCL mess. (from the OpenCL git linked above)
Why are DPC++ and OpenSYCL changes not merged higher in the tree? This seems like an awfully lot of separate efforts to distribute workloads.
Why don't we have the primary SYCL runtime library distributing to the various "branches" of SYCL, then to the runtime plugins, and backends from there?

They both work very differently. Open SYCL supports a whole ton of compilation flows that DPC++ was never designed for. And there are also some use cases that DPC++ supports that Open SYCL does not. You cannot just merge the two. You might as well ask, why is gcc not merged with clang?
They are just two different SYCL implementation projects with different goals. Their runtime interfaces and designs are very different, too.
Open SYCL/hipSYCL predates DPC++. Ask Intel why they felt the need to create something new instead of working on Open SYCL.

What you see here is a healthy, multi-vendor ecosystem. This is what you want for an open standard. A standard that only has a single implementation is pointless - the whole point of having a specification is to allow for multiple implementations.
This in turn allows end users to test their code with multiple implementations (all of which have their strengths and weaknesses), allowing users to find the implementation that is fine-tuned for their use case. Testing with multiple implementations can also be important to find bugs.

With AMD and Intel both having hefty open source driver stacks, and both being the underdogs, it seems they both could have a better interop strat in place - they only have "up" to go in terms of datacenter and consumer compute add-in board sales. Additionally, it seems advantageous for them to add their Movidius and Xilinx stacks to SYCL.

Maybe, but AMD does not officially have SYCL in their strategy. Open SYCL/hipSYCL is not an AMD project.

Additionally: syscl-gtx seems like it would be super critical as a fallback! This would work well for the Arm Mali, Broadcom, and other OpenCL efforts along with rusticl to have true cohesion even if other device types aren't supported.

It hasn't been maintained for years, and was always incomplete, and more of a research project than intended for production. The three big production SYCL implementations are DPC++, Open SYCL/hipSYCL and ComputeCpp. The others are more niche, experimental and/or research projects.
OpenCL 1.2 lacks capabilities to implement more modern versions of SYCL on top of it, unless you're willing to go into source-to-source translation realm which is probably going to be brittle. There's a reason why SYCL implementations work the way they work.

[Eirikr1848]

I agree with you 100% and I don’t have the words to express correctly that I wish for there to be an “interop layer” to grab the valid workflows and delegate “downstream” for “decision making”. This is what I’m talking about by “merging efforts” — not a git merge, but a combining of efforts for this.

They both work very differently. Open SYCL supports a whole ton of compilation flows that DPC++ was never designed for. And there are also some use cases that DPC++ supports that Open SYCL does not. You cannot just merge the two. You might as well ask, why is gcc not merged with clang?
They are just two different SYCL implementation projects with different goals. Their runtime interfaces and designs are very different, too.
Open SYCL/hipSYCL predates DPC++. Ask Intel why they felt the need to create something new instead of working on Open SYCL.

What you see here is a healthy, multi-vendor ecosystem. This is what you want for an open standard. A standard that only has a single implementation is pointless - the whole point of having a specification is to allow for multiple implementations.
This in turn allows end users to test their code with multiple implementations (all of which have their strengths and weaknesses), allowing users to find the implementation that is fine-tuned for their use case. Testing with multiple implementations can also be important to find bugs.



Maybe, but AMD does not officially have SYCL in their strategy. Open SYCL/hipSYCL is not an AMD project.



It hasn't been maintained for years, and was always incomplete, and more of a research project than intended for production. The three big production SYCL implementations are DPC++, Open SYCL/hipSYCL and ComputeCpp. The others are more niche, experimental and/or research projects.
OpenCL 1.2 lacks capabilities to implement more modern versions of SYCL on top of it, unless you're willing to go into source-to-source translation realm which is probably going to be brittle. There's a reason why SYCL implementations work the way they work.