OpenCL 3.0.16 Released With One New Extension, Semaphores & External Memory Finalized

[coder]

Is any program really making use of OpenCL?

It forms the basis for SYCL and Intel's oneAPI. Pay attention to who is contributing:

"The cl_khr_kernel_clock kernel clock extension was worked on by Arm, Imagination, Intel, and Qualcomm engineers."

Speaking of oneAPI and CUDA, Intel, Google, and Qualcomm recently announced an alliance to promote oneAPI, in the face of the CUDA behemoth:

https://www.tweaktown.com/news/97113/google-intel-qualcomm-fighting-nvidias-dominance-on-ai-gpus-with-cuda-software-alternative/index.html

It would be so nice if we had something that would "simply work"(TM).

That's why I'm very interested in the progress of Rusticle. For OpenCL to have any chance of taking back market share, it needs to be as dependable as OpenGL and Vulkan acceleration have become.

[coder]

They did their part to sabotage it. But you can also fault shintel, AMD and the kronos group.

https://news.ycombinator.com/item?id=38658903#:~:text=It%20could%20be%20argued% 20that%20Nvidia%20sabotaged%20OpenCL.,but%20OpenCL %20couldn%27t%20succeed%20without%20good%20support %20Nvidia.

WTF? You just find a post on another site to link to, as if it's some kind of actual source?

The main reason OpenCL never gained critical mass was because none of the big platforms ever required it. In contrast, I credit Android for the main reason Vulkan happened. Hopefully, Google's backing of oneAPI will mean good things for OpenCL.

Here's a list even https://en.wikipedia.org/wiki/List_o...L_applications

That includes some libraries, like OpenCV. But, a lot of apps link in OpenCV. So, potential support may be more widespread than it seems.

[coder]

Jokes aside, I know that OpenCL is not perfect, and probably like 10% slower than dedicated API, but still I don't quite get why it's so unpopular especially in open source world, that cares about freedom etc.

Because it's not ubiquitous. Imagine some Linux distro/hardware/driver combinations supported Vulkan while others supported OpenGL, but neither API was supported by everything, everywhere. How destructive do you think that would be for the adoption of either?

OpenCL needs to work virtually everywhere, out of the box. That will drive adoption. I've found support to be solid on Intel iGPUs for many years, at least to the extent I've used it.

[sobrus]

OpenCL needs to work virtually everywhere, out of the box. That will drive adoption. I've found support to be solid on Intel iGPUs for many years, at least to the extent I've used it.

Same with AMD. Even though usually GPGPU on AMD is crap, it worked just as well on RX570 as it does on RX6800XT.
What is more, to run OpenCL you don't even have to install full rocm and hip sdk, which is like 20GiB of packages to install, at least on Arch linux and derivatives.
rusticl may improve this even more.

That only leaves nvidia, but in this case lack of opencl support is a lesser problem, as it doesn't have open source drivers in the first place.
(I'm not couting nouveau, because it offered like 10% of performance anyway).
So nVIdia is strong enough to prevent adoption of open standards on open platforms. I wonder if microsoft released closed source DX12 for linux, would anybody use Vulkan?

And if render farms somehow switched to macOS overnight, would blender drop linux support just like it dropped OpenCL? Because there is a better, proprietary solution.

[coder]

That only leaves nvidia, but in this case lack of opencl support is a lesser problem, as it doesn't have open source drivers in the first place.

They support it*, but the question is one of which feature set? For a long time, they remained stuck at v1.2, with 2.0 support stuck in beta. When 3.0 launched, they quickly upgraded to that, but I doubt the actual feature set expanded much, since 3.0 makes a lot of things optional.

* The big exception for OpenCL support on Nvidia hardware is their SoC iGPUs. As far as I'm aware, they generally don't support OpenCL on those.

[qarium]

WTF? You just find a post on another site to link to, as if it's some kind of actual source?
The main reason OpenCL never gained critical mass was because none of the big platforms ever required it. In contrast, I credit Android for the main reason Vulkan happened. Hopefully, Google's backing of oneAPI will mean good things for OpenCL.
That includes some libraries, like OpenCV. But, a lot of apps link in OpenCV. So, potential support may be more widespread than it seems.

most people don't realize that of you do Vulkan Compute it runs everywhere and is much faster.

also keep in mind people say ROCm/HIP is garbage because of bugs that ROCm/HIP copy from CUDA with bug for bug compatibility
all these CUDA source-code-level emulations like ROCm/HIP and oneAPI similar to as a high-level API

in my point of view low-level assembler like APIs like Vulkan Compute will in the end beat all these high level APIs like CUDA,HIP,oneAPi

[coder]

most people don't realize that of you do Vulkan Compute it runs everywhere and is much faster.

On a lot of fronts, this is misleading at best.

Some deficiencies of Vulkan are that:

• it doesn't define a kernel language, forcing users to use additional toolchains and libraries or build steps for this.
• it requires only the same precision as OpenGL shaders, making it unsuitable for scientific or financial computation.
• it has tons of optional features that make the notion of "runs everywhere" laughable, unless you're using just the bare minimum functionality.
• it's way lower-level and requires a lot more work from application developers to use, not to mention efficiency.
• it does nothing to address OpenCL's main drawbacks, such as things like unsatisfactory performance portability.
• current CPU implementations don't scale well.
• it lacks support on certain architectures & devices that support OpenCL, such as FPGAs. Sometimes, having a more general solution is worse, because it would be impractical for something like a FPGA to support Vulkan, whereas supporting a more targeted solution is feasible.
• probably also not supported on pure (i.e. not graphics) compute accelerators, like MI300.

Basically, if Vulkan Compute were such a great solution, it would already have a lot of momentum behind it and probably be seen as the main CUDA challenger. However, basically none of the GPU Compute stakeholders seem to regard it as such.

[qarium]

On a lot of fronts, this is misleading at best. Some deficiencies of Vulkan are that: it doesn't define a kernel language, forcing users to use additional toolchains and libraries or build steps for this.

dude this is the best part ... you can use RUST... compare it with OpenCL it enforce outdated C style language
this makes it much more flexible because if something much better emerge like RUST then you can use the much better language.
the point that OpenCL is a C style language dialect is the best indication that OpenCL will die.
it is same bullshit with HIP/Cuda that many backend kernels are writen in C++ what makes it complete shit.

it requires only the same precision as OpenGL shaders, making it unsuitable for scientific or financial computation.

thats clearly wrong you can use vulkan extensions who use higher precision.

it has tons of optional features that make the notion of "runs everywhere" laughable, unless you're using just the bare minimum functionality.

this is only a problem if you fokus on closed source drivers like Nvidia if you focus on open source mesa drivers and amd hardware you can implement the vulkan extensions you need in the mesa driver ....
then the "runs everywhere" becomes a "you can make it run everywhere" because you can develop the extensions in mesa for the hardware you use.
this clear seperation what you put in mesa and what you put in your code results in a very clean codebase.

it's way lower-level and requires a lot more work from application developers to use, not to mention efficiency.

this is true but there are already benchmarks who proof that this results in much higher performance.

it does nothing to address OpenCL's main drawbacks, such as things like unsatisfactory performance portability. current CPU implementations don't scale well. it lacks support on certain architectures & devices that support OpenCL, such as FPGAs. Sometimes, having a more general solution is worse, because it would be impractical for something like a FPGA to support Vulkan, whereas supporting a more targeted solution is feasible. probably also not supported on pure (i.e. not graphics) compute accelerators, like MI300.

once bridgman told me MI300 supports Vulkan Compute ... it only does not support vulkan graphics.

why exactly should FPGA not support vulkan? you can do everything with FPGA its the most flexible chip design

Basically, if Vulkan Compute were such a great solution, it would already have a lot of momentum behind it and probably be seen as the main CUDA challenger. However, basically none of the GPU Compute stakeholders seem to regard it as such.

to fight a monopole like CUDA you really need more than a great solution...

[coder]

dude this is the best part ... you can use RUST... compare it with OpenCL it enforce outdated C style language
this makes it much more flexible because if something much better emerge like RUST then you can use the much better language.

It lacks certain expressiveness found in the OpenCL kernel language and its ability to generate efficient GPU SIMD is unproven.

More importantly, for some: every OpenCL has the ability to compile kernels at runtime, which some OpenCL users take advantage of to enable dynamic code generation.

the point that OpenCL is a C style language dialect is the best indication that OpenCL will die.

First off, no. Secondly, there's always SYCL.

it is same bullshit with HIP/Cuda that many backend kernels are writen in C++ what makes it complete shit.

Heh, you drink deeply of the Rust Kool-aid, yet I'm sure you've never done serious programming in either. Don't be so dogmatic, especially about stuff you don't actually know.

thats clearly wrong you can use vulkan extensions who use higher precision.

Oh, but then it doesn't "run everywhere"!

this is only a problem if you fokus on closed source drivers like Nvidia

Wrong. I gave examples of specialized devices, like FPGAs (and there's also various NPUs) that cannot support the required featureset of Vulkan, but do support OpenCL.

if you focus on open source mesa drivers and amd hardware you can implement the vulkan extensions you need in the mesa driver ....

That assumes there's even Mesa support for the hardware. Then, you're trivializing the amount of work needed add Vulkan support for it, in Mesa.

then the "runs everywhere" becomes a "you can make it run everywhere" because you can develop the extensions in mesa for the hardware you use.

Some hardware lacks needed Vulkan extensions for hardware reasons, not software.

this clear seperation what you put in mesa and what you put in your code results in a very clean codebase.

It's even cleaner with OpenCL.

this is true but there are already benchmarks who proof that this results in much higher performance.

If you have a bad OpenCL implementation and a good Vulkan implementation, you can get better performance via optimized Vulkan code. However, there's nothing about Vulkan that's inherently faster. You've simply drank the Kool-aid. You are a known Kool-aid drinker (i.e. cultist).

once bridgman told me MI300 supports Vulkan Compute ... it only does not support vulkan graphics.

Thanks. Interesting datapoint. I'm sure there are some examples of compute or AI accelerators where OpenCL support is feasible (or even present), yet Vulkan is not.

why exactly should FPGA not support vulkan? you can do everything with FPGA its the most flexible chip design

Show me a FPGA that supports Vulkan.

[qarium]

It lacks certain expressiveness found in the OpenCL kernel language and its ability to generate efficient GPU SIMD is unproven.
More importantly, for some: every OpenCL has the ability to compile kernels at runtime, which some OpenCL users take advantage of to enable dynamic code generation.
First off, no. Secondly, there's always SYCL.
Heh, you drink deeply of the Rust Kool-aid, yet I'm sure you've never done serious programming in either. Don't be so dogmatic, especially about stuff you don't actually know.
Oh, but then it doesn't "run everywhere"!
Wrong. I gave examples of specialized devices, like FPGAs (and there's also various NPUs) that cannot support the required featureset of Vulkan, but do support OpenCL.
That assumes there's even Mesa support for the hardware. Then, you're trivializing the amount of work needed add Vulkan support for it, in Mesa.
Some hardware lacks needed Vulkan extensions for hardware reasons, not software.
It's even cleaner with OpenCL.
If you have a bad OpenCL implementation and a good Vulkan implementation, you can get better performance via optimized Vulkan code. However, there's nothing about Vulkan that's inherently faster. You've simply drank the Kool-aid. You are a known Kool-aid drinker (i.e. cultist).
Thanks. Interesting datapoint. I'm sure there are some examples of compute or AI accelerators where OpenCL support is feasible (or even present), yet Vulkan is not.
Show me a FPGA that supports Vulkan.

there are already people who post benchmarks between openCL and Vulkan Compute and in their micro bechmarks vulkan won big...

OpenCL is litterally death in the market the reason is Nvidia did only support 1.2 and only after OpenCL3.0 did drop any feature to be requirement for expose OpenCL3.0 feature level then Nvidia now claims they support OpenCL3.0 but if you check feature level they still only support OpenCL1.2 means for Nvidia they only support legacy apps in OpenCL..

its even worst relevant apps like Blender did even drop OpenCL completely because it never worked for complex projects.

so in my point of view OpenCL is DEATH...

"Kool-aid drinker (i.e. cultist)"

you can call me names all you want but i am pretty sure people have more interest in Vulkan Compute with RUST than people believe in OpenCL...

"every OpenCL has the ability to compile kernels at runtime, which some OpenCL users take advantage of to enable dynamic code generation."

yes Python also has the ability to do it at runtime but people still chose RUST and do not want this feature at all.

there are even people who litterally gave up on Python because of the extension chaos and different install packet systems for extensions

they say Rust is better because they mostly have only 1 source for extensions and you can even set this source to MIT License only and by this you can ignore all the license problems.

this makes Rust much more easy to develop for than Python... this multible compiler problem you have it with C and C++ a lot but right now there is only 1 compiler for Rust.. i know the GCC people work on their rust support but right now no one use the GCC for rust because it is highly experimental and does not support the features to compile modern rust code.

also there are C vs rust benchmarks who proof that rust outperforms C and well OpenCL more or less use a C dialect

about FPGA you know that there is a professor who released a AMD ISA open-source implementation for FPGAs to emulate a AMD GPU??

https://miaowgpu.org/

https://pages.cs.wisc.edu/~vinay/pubs/MIAOW-HotChips.pdf

https://old.hotchips.org/wp-content/uploads/hc_archives/hc27/HC27.25-Tuesday-Epub/HC27.25.50-GPU-Epub/HC27.25.512-MIAOW-Balasubramaniam-UWisc-v1.2.pdf

here you see you can run it on a FPGA

maybe you can not produce a chip with that because of patents but you can run it on a FPGA...