Intel's Linux Compute Stack Now Boasts Production-Ready OpenCL 3.0, Integrates IGSC FU

[phoronix]

Phoronix: Intel's Linux Compute Stack Now Boasts Production-Ready OpenCL 3.0, Integrates IGSC FU

Shortly after OpenCL 3.0 was finalized last year it was enabled for Intel's open-source Compute Runtime stack (and even earlier with their Tiger Lake enablement). But since last year that OpenCL 3.0 support was marked as "beta" while last week was quietly promoted to being "production" grade...

https://www.phoronix.com/scan.php?page=news_item&px=OpenCL-3.0-Intel-Production

[uid313]

Now we need OpenGL 3.0 support from AMD and Nvidia too, else few applications are going to bother with implementing support for OpenCL.

[MadeUpName]

So is this going to be actual packages that you can get with your distro that provide openCL 3.0 on the shaders rather than just on the CPU? Will it include image support? If so it will completely change whats in my next laptop. I will be more than happy to take the CPU and power hit in order to have a laptop that is actually useful for more than email. This could be a total game changer for me.

[ms178]

Maybe I am mistaken, but my impression is that OpenCL lost quite some traction over the past decade and ROCm, oneAPI, SYCL or VulkanCompute will make it less and less relevant over the next decade.

[MadeUpName]

ROCm is the driver, openCL is the language. openCL certainly has had it's ups and downs but no application I use has ported away from openCL at this point.
That doesn't mean they aren't working towards it, I don't know . In any case I don't expect AMD or NVidia to support any new API/Language in the consumer space any better than they did openCL If you want to install the proprietary drivers and then never be able to patch your system again you can get openCL working but the juice isn't worth the squeeze. I have a seperate OS I boot into just to work with openCL that will never be patched, it is a pain in the ass but it is what I have to do in order to use apps that require it. At least NVidia is honest and will tell you right up front they don't give a F about openCL. AMD keeps dribbling out this "Just buy our stuff, we will make it work some day" non-sense for the gullible.

[coder]

Now we need OpenGL 3.0 support from AMD and Nvidia too, else few applications are going to bother with implementing support for OpenCL.

Nvidia had 3.0 for a while, so it should just be ROCm that's lagging.

https://developer.nvidia.com/blog/nvidia-is-now-opencl-3-0-conformant/

[coder]

Maybe I am mistaken, but my impression is that OpenCL lost quite some traction over the past decade and ROCm, oneAPI, SYCL or VulkanCompute will make it less and less relevant over the next decade.

As MadeUpName said, ROCm is the driver stack rather than the compute API.

Intel's oneAPI is built on SYCL, which itself is built on OpenCL.

Vulkan Compute is often talked about, but has yet to meaningfully materialize. Vukan is a lower-level API (i.e. more work to use) and offers lower precision guarantees than OpenCL. So far, no vendor is all-in. Everyone is invested in something else: AMD in HiP, Nvidia in CUDA, and Intel in oneAPI. And all the AI compute guys have their own proprietary stuff.

[coder]

If you want to install the proprietary drivers and then never be able to patch your system again you can get openCL working but the juice isn't worth the squeeze.

All of the open source drivers have some degree of OpenCL support (basically 1.2).

https://mesamatrix.net
(scroll to the bottom although doesn't seem updated since Feb?)

In Intel's case, it doesn't require proprietary drivers (Intel has no such thing), but it's a separate install.

At least NVidia is honest and will tell you right up front they don't give a F about openCL.

They had 2.x support in beta forever, but now officially support 3.0.

AMD keeps dribbling out this "Just buy our stuff, we will make it work some day" non-sense for the gullible.

AMD's issue isn't really OpenCL support -- it's consumer hardware. As for OpenCL, they're already at 2.2. Adding 3.0 should be an easy step.

[quaz0r]

i still cant get over what a cucked out epic failburger opencl "3" is. ugh, khronos, seriously, it burns. it burns. and now all these shameless mfers can loudly declare how they support the latest standard... jfc its so gross. i gotta go look at the inside of a toilet bowl now to cleanse my eyes of this bs.

[coder]

i still cant get over what a cucked out epic failburger opencl "3" is. ugh, khronos, seriously, it burns. it burns. and now all these shameless mfers can loudly declare how they support the latest standard... jfc its so gross. i gotta go look at the inside of a toilet bowl now to cleanse my eyes of this bs.

That seems rather... hyperbolic. All we need is something like Mesa Matrix to track which implementations support which features.

The funny thing is that most other popular APIs had this notion of optional features and the ability to dynamically query for their availability, including Vulkan. Yet, when OpenCL goes down that same path, a bunch of people scream "bloody murder". It's about as big a double standard as you'll find.