Update the SYCL implementations diagram

[rafbiels]

Replace the PNG with an SVG and update the content to reflect the current state of the implementations.

[illuhad]

Why is the line from AdaptiveCpp to SPIR-V dashed? And why is it important to highlight that it internally uses JIT? Isn't this just an implementation detail?

Also, while we do support OpenCL, we do not support Intel FPGAs as listed there. Perhaps it might be better to have separate OpenCL nodes for the implementations?

[DuncanMcBain]

We're making updates to the image, but we're basically all done for the year here now. We'll post an update in the new year to this branch (and meantime I'll stop it being merged).

[DuncanMcBain]

changing to request changes to allow for updates come January.

[rafbiels]

Hi @illuhad, I can see your point of view. I think you could say that JIT vs AOT is an implementation detail. I updated the diagram merging identical nodes between DPC++ and AdaptiveCpp and removed any mention of JIT. I hope the new version is clearer and less cluttered. Let me know what you think. I also changed "Intel FPGAs" to "Intel FPGAs (DPC++)" to flag that AdaptiveCpp doesn't support this.

[illuhad]

Looks much better than what we had previously, thanks!

It's an interesting change to formulate the diagram in terms of targeted device code formats rather than runtime library backends as we did before.

I don't have a strong preference for one or the other, but if you have some thoughts about this, I'd be curious to hear more about the rationale :)

Not a request for changes nor a strong preference, just something I'd like to point out: For consistency we could also combine Native CPU/OpenMP into "native host ISA" or similar to formulate it from the perspective of generated code.

PS: Happy new year :)

[hdelan]

I really like this new diagram. Nice one @rafbiels !

[rafbiels]

Thank you for the feedback @illuhad and happy new year to you too! :) I'm glad you like the new version of the diagram.

My thinking for the diagram was that it reflects the "write once - run anywhere" aspect of SYCL and helps to explain what happens to the user's computation (kernel code) in the compilers. I think it's interesting to highlight what the different compilers can do to the device code and how SYCL achieves its multi-platform portability. The diagram shows that the same input (SYCL kernel code) can be compiled into various vendor-specific representations and each compiler offers slightly different "outputs" which can be used to target various hardware. The runtime library details didn't seem as important to me in this context (other than the distinction that SPIR-V output can feed two runtimes).

I opted for the PTX / GCN / SPIR-V / "CPU code" / OpenMP labels as in my experience this is what most people use as short names for backend-specific output of SYCL device code compilation. I appreciate this scheme is inconsistent as GCN is an ISA family whereas PTX and SPIR-V are intermediate representations lowered later to CUDA SASS / Intel Gen Assembly / x86 Assembly. Using the latter names would be technically more correct, but in my view confusing as SASS and Gen ISA lack public documentation and are rarely discussed.

tl;dr: my focus was on device code and on short recognisable names for the outputs.

[illuhad]

Thanks for the details @rafbiels. This all makes sense to me.

These diagrams I think ultimately were inspired by the original SYCL implementation diagram that I did in 2018/2019-ish which was formulated in terms of runtime backends. The other diagrams that came after e.g. on the Khronos slides or SYCLacademy inherited and improved on this. My original rationale back then was that this would explain users "what they need". E.g. If you have an NVIDIA GPU, then you need to install CUDA and find a SYCL implementation with CUDA backend.

But I can see that for the purpose of explaining how SYCL works on the compiler side this approach might be better. So it's clear to me now that we might need different specialized diagrams for different use cases, e.g. describing how SYCL works vs documenting the ecosystem or providing guidance for users :)

I appreciate this scheme is inconsistent as GCN is an ISA family whereas PTX and SPIR-V are intermediate representations lowered later to CUDA SASS / Intel Gen Assembly / x86 Assembly. Using the latter names would be technically more correct, but in my view confusing as SASS and Gen ISA lack public documentation and are rarely discussed.

I suppose you can argue that Gen ISA or SASS might be implementation details, as SYCL compilers generate PTX or SPIR-V. They might then in some cases process this further to SASS/gen ISA for pure AOT semantics, but this is optional and may or may not happen depending on implementation, target hardware and selected compilation flow.

[rafbiels]

I wasn't aware of the backstory of the diagram - that's good to know! I agree we might need different versions for other purposes. Thankfully, the SVG format should be easy enough to edit and I'm happy with people taking it and making their own.