How portable is will SYCL code be across the different toolchains?

[jon-chuang]

While SYCL is still a developing standard, I am wondering about portability. For instance, I may not simply want to compile to Spir-V, but also use hipSYCL. While of course this may vary from compiler to compiler which may offer different features, I don't have a picture of just how interoperable SYCL is meant to be. I suppose I have to keep track of which compilers support which features.

[illuhad]

Are you looking at any features in particular? Otherwise, I can only give a very general answer: While SYCL as a standard continues to move forward, SYCL 1.2.1 is already there - so, SYCL 1.2.1 conformant code should work on any SYCL 1.2.1 conformant SYCL implementation. With that said, neither Intel SYCL nor hipSYCL are conformant yet because both implementations are still young and in development. As SYCL implementations mature, we should expect more implementations to reach official conformance.
While SYCL conformance is about functional portability, for performance portability, there may be certain constructs that are efficient for one combination of SYCL implementation and hardware architecture and less efficient for another one.

[AlexeySachkov]

Hi @jon-chuang,

While SYCL is still a developing standard, I am wondering about portability. For instance, I may not simply want to compile to Spir-V, but also use hipSYCL.

If I understand correctly, SYCL spec doesn't describe SPIR-V at all: you just write SYCL code, compile it with corresponding compiler and then launch resulting application. As @illuhad pointed out, if you stick with SYCL 1.2.1 features (or with any other specification version), then your code should behave in the same way using any conformant implementation (unless you don't exploit UBs, of course)

While of course this may vary from compiler to compiler which may offer different features, I don't have a picture of just how interoperable SYCL is meant to be. I suppose I have to keep track of which compilers support which features.

Apparently, each vendor/implementation will provide extensions to enable additional features which benefit from particular hardware - how this will look is still an open question: SYCL specification doesn't define any extensions mechanism (you can ask about it in KhronosGroup/SYCL-Docs, I guess).

In intel/llvm we documented and implemented support of some extensions and there is a discussion about how to control which extensions are enabled/disabled, see #806: there most likely will be some compatibility/strict mode which allows you to discard all non-standard constructs to ensure that your code is still portable

[Ruyk]

The core of the SYCL specification is compatible across conformant implementations. The idea of conformance process is that implementations must pass a set of tests (in the case of SYCL 1.2.1, https://github.com/KhronosGroup/SYCL-CTS) for an implementation to be declared as "conformant". This means the complete set of features and API are supported.
Vendor specific extensions can be exposed on vendor namespaces (e.g. cl::sycl::codeplay::).
As mentioned before, there is no extension mechanism for SYCL 1.2.1.
Codeplay documents all extensions and proposals in our Standards Proposals repository.

Currently, the SYCL WG is focusing their efforts on addressing feedback on SYCL 1.2.1 and the next SYCL version. There are some ideas about a SYCL extension mechanism, but, in my personal view, I wouldn't expect that to come out for 1.2.1 any time soon.

ComputeCpp and Intel SYCL (maybe others) are trying to align on many different things, for example, compilation flags (e.g. -sycl-std) and platform information (e.g. https://github.com/codeplaysoftware/sycl-info). From Codeplay perspective, we are looking at which Intel's extensions are relevant to us and looking at a roll-out plan for them.

There are some open questions still to solve for compatibility across toolchains, e.g. ABI, common headers, distribution and dependencies... but we are all working on this and listening to user feedback to see which direction we should take.

[AlexeySachkov]

@jon-chuang, was the question answered? Can we close the issue?

[jon-chuang]

Hi, yes, thanks for the great answers!