Intel's oneAPI Is Coming To AMD Radeon GPUs

[phoronix]

Phoronix: Intel's oneAPI Is Coming To AMD Radeon GPUs

While yesterday brought the release of Intel's oneAPI 1.0 specification, the interesting news today is that oneAPI support is coming to AMD Radeon graphics cards...

http://www.phoronix.com/scan.php?page=news_item&px=oneAPI-AMD-Radeon-GPUs

[xxmitsu]

Wow, this is great news!

[ms178]

The details would be interesting as I would consider hipSYCL to be on a higher abstraction level than having Level-0-support also for AMD.

[illuhad]

The details would be interesting as I would consider hipSYCL to be on a higher abstraction level than having Level-0-support also for AMD.

See our official press release: https://urz.uni-heidelberg.de/en/202...oneapi-coe-urz

The phoronix article is maybe somewhat misleading. This is about improving SYCL 2020 support in hipSYCL such that code that works with DPC++ (which is basically an implementation of SYCL 2020) also works with hipSYCL.

[Michael]

See our official press release: https://urz.uni-heidelberg.de/en/202...oneapi-coe-urz

The phoronix article is maybe somewhat misleading. This is about improving SYCL 2020 support in hipSYCL such that code that works with DPC++ (which is basically an implementation of SYCL 2020) also works with hipSYCL.

Would you say then your effort is more about SYCL 2020 than oneAPI? FWIW, here is how it was reported to me yesterday by Intel PR rep, "Tomorrow, Intel and Heidelberg University Computing Center (URZ) will be introducing a newly established oneAPI Academic Center of Excellence at URZ. Together, Intel and URZ will expand oneAPI’s capabilities in support of AMD GPUs." without any SYCL 2020 specifics mentioned.

[illuhad]

Would you say then your effort is more about SYCL 2020 than oneAPI? FWIW, here is how it was reported to me yesterday by Intel PR rep, "Tomorrow, Intel and Heidelberg University Computing Center (URZ) will be introducing a newly established oneAPI Academic Center of Excellence at URZ. Together, Intel and URZ will expand oneAPI’s capabilities in support of AMD GPUs." without any SYCL 2020 specifics mentioned.

So the language behind oneAPI for direct programming is SYCL 2020. SYCL 2020 however has not yet officially been fully finalized and exists only in the form of the SYCL 2020 provisional specification - Intel calls the language (oneAPI) DPC++, but it's basically the same thing. Whether people call it SYCL 2020 or DPC++ is, for the most part, a matter of preference.

Additionally oneAPI contains a lot of other stuff - libraries for linear algebra, data analytics, tooling etc.

We are, at least at the moment, focusing on the language, not the libraries. So, it's correct to say that this work will extend SYCL 2020 in hipSYCL and also that it will "extend its oneAPI capabilities" (by interpreting the SYCL2020/DPC++ language as part of oneAPI) and that it will improve portability of code written for oneAPI using DPC++/SYCL 2020.

Claiming that we will bring all of oneAPI to AMD might be a bit of a stretch, at least for now, because we are focusing on the language, not all of the libraries and tooling etc. Additionally, which might add to the confusion, oneAPI can also refer to Intel's software stack (i.e. implementation), from which we are however independent. Basically we are improving the compatibility between two SYCL implementations, which however also has implications on the oneAPI ecosystem. So, the Intel rep is still correct

[Vistaus]

Great news, but not for the people on this site who still think Intel doesn't give a crap about supporting AMD hardware.

[Jumbotron]

Great news, but not for the people on this site who still think Intel doesn't give a crap about supporting AMD hardware.

Well....I would not get all ecumenical so fast there buddy. Intel will NEVER knowingly support a competitor, who, by their very existence cuts into Intel's profit margin and market share.

What we have is more support flowing or potentially flowing to AMD simply because both Intel and AMD are x86 based and are platforms for C/C++ and derivatives. What ever help and support AMD receives from this is more of a knock on effect more than direct help from Intel.

[ms178]

See our official press release: https://urz.uni-heidelberg.de/en/202...oneapi-coe-urz

The phoronix article is maybe somewhat misleading. This is about improving SYCL 2020 support in hipSYCL such that code that works with DPC++ (which is basically an implementation of SYCL 2020) also works with hipSYCL.

Thanks a lot for the provided details. As AMD is not officially vocal about backing SYCL (at least in public, maybe they do engage actively inside Khronos), it is quite interesting that Intel sponsors your ongoing work. I would have assumed that AMD would have an interest in your project and provided that sponsorship. That makes me wonder what the current state of play for AMD looks like concerning their compute software stack. As I understand it they are heavily invested into LLVM/ROCm ecosystem and derive also their OpenCL, SPIR, SPIR-V work and HIP from there. Albeit starting some research with SYCL themselves, that work (and the developer) moved on to Xilinx.

They did build their HCC compiler though instead of investing into SYCL and I don't even know if they deprecated it (as they announced some releases ago) or not. Their intentions on supporting OpenCL beyond 2.2 are also not clear to me - ROCm hardware support is also still limited to GFX8 and GFX9 to this date. It would be great to get an updated presentation from them how they plan to move forward in the data center. But since Greg Stoner left I haven't read anything new in this regard and it is still somewhat confusing how they want to tackle this task.

[oleid]

A little off topic, but I was wondering:

It is well known that (at least for radv) the AOC shader complier is in general superior to the one based on the Radeon llvm backend.

What would it take to wire AOC up as kind of a way to generate code for sycl?
Maybe illuhad knows more?