
Khronos Announces OpenCL 3.0 - XzetaU8
https://www.anandtech.com/show/15746/opencl-30-announced-hitting-reset-on-compute-frameworks
======
fluffything
>So today Khronos is doing something for which I’m not sure there’s any
parallel for in the computing industry – and certainly, there’s never been
anything like it in the GPU computing ecosystem: the framework is taking a
large step backwards. Looking to reset the ecosystem,

The people who picked up CUDA can now easily compile it to target NVIDA and
AMD GPUs, as well as x86-64 CPUs, using a pletora of compilers (nvcc, hip's
framework, PGI compiler for CUDA->x86, Intel's CUDA compiler, ...). Each
upgrade to the CUDA platform has been backward compatible, and improved
performance by quite a bit.

Those who went for OpenCL lost Apple's platform support, have so-so AMD and
Intel CPU support, and not so great AMD and NVIDIA GPU support, and now are
getting an "ecosystem reset".

I find this quite ironic TBH. The main advantage of OpenCL over CUDA on paper
was supposed to be the vendor portability, but CUDA is delivering better on
that "feature" than OpenCL.

And now they land an ecosystem reset. I hope that people can easily migrate
their OpenCL 2.x code to OpenCL 3.0. If doing that requires a rewrite, they
might as well rewrite their code in CUDA..

~~~
pjmlp
It is like Khronos keeps missing the point why developers jump into more
productive eco-systems.

Lets see how they manage Vulkan, which keeps getting extensions that NVidia
and AMD first develop in DirectX anyway, like Raytracing and mesh shaders.

Google and Samsung had to adapt Microsoft's HLSL compiler to target SPIR-V,
because plenty of game developers weren't willing to write GLSL, or to port
their shaders.

For those that don't know shading languages HLSL is closer to C++ in language
features, also similar to what PS4 uses, while GLSL is pretty much still stuck
in being a C derived shading language.

~~~
ksec
>It is like Khronos keeps missing the point why developers jump into more
productive eco-systems.

They have a history of doing it for the past 20 years. So when the article
said "Taking some hard earned (and hard learned) lessons to heart,". I
laughed.

I am not even sure they learned anything. And it is the same reason I dont
understand why everyone is chanting Vulkan. It is the same /similar story with
OpenGL vs 3DFx Glide.

~~~
skohan
Vulkan is a breath of fresh air compared to OpenGL. The documentation is
great, it runs everywhere, and if it passes validation I get consistent
results on whatever hardware I want to run it on.

I'm not sure why I would want to target 4+ proprietary API's instead of one
modern, open API which is well-designed and performs great.

~~~
pjmlp
Just wait a couple of releases more until the extension registry starts
matching the OpenGL one, and one needs to write multiple code paths depending
on the targeted GPUs.

~~~
skohan
Is that not equally true of DX12? How can I execute mesh shaders on hardware
which doesn't support them?

This is not a sin of Vulkan, it's just the reality of a fragmented GPU
landscape.

At least Vulkan has a sensible, consistent API around extensions, and makes it
easy to verify that your hardware has the capabilities you need in order to
use a given feature.

~~~
pjmlp
It won't start at all because it requires DirectX 12 Ultimate drivers.

~~~
skohan
DirectX 12 Ultimate is a different thing than DirectX 12. Game developers
aren't just going to be able to target Ultimate if they want to capture any
users with older than current generation NVIDIA or next gen AMD GPUs.

edit: if I was using Vulkan and only wanted to target DX12 Ultimate-certified
hardware I would still be able to use only one code-path. This would basically
mean that I am choosing to only support hardware which supports a certain set
of extensions

~~~
pjmlp
They have enough customers on XBox ecosystem.

~~~
skohan
You’re arguing that DX12 is better than Vulkan because it has exactly the same
characteristics as Vulkan.

~~~
pjmlp
If only Vulkan had an SDK half as good.

~~~
skohan
That wasn't your argument but go ahead and move the goal posts all you want.

~~~
pjmlp
No, the original argument was that DirectX, or any other proprietary API from
Apple, Nintendo and Sony, don't need the extension jungle of Vulkan and
OpenGL, the former with almost weekly updates.

Which than feds into learning the APIs and not having to deal with multiple
execution paths.

In DirectX there is only one way of doing RayTracing, in the Khronos APIs,
well it depends. Same applies to lots of other features.

~~~
skohan
You're comparing apples and oranges. Your argument is that proprietary API's
are better than Vulkan because there are less code paths, but if you go that
way _you need a completely separate code path for each top-level API_.

I think you're vastly over-stating the complexity of handling this in Vulkan.
For the ray-tracing example, realistically you have one branch for non-ray-
tracing, and one more where you check for whatever RT extensions you need and
do ray-tracing if you have them available. This is exactly the same complexity
you would have with DX12.

DX12 Ultimate is a really poor counterpoint. No serious game developer is
going to be content targeting _only_ XBoxSX and PCs build for over $1200 in
the last 18 months. Realistically, even if you _only_ target MS platforms,
you're probably even going to need a DX11 renderer, and the DX12 API is
already quite different on XBox and PC, so that's already 3 code-paths
minimum.

------
raphlinus
My personal take on this is that OpenCL is not the way forward, that
deployment is going to be on Vulkan and likely WebGPU. But there is an
enormous gap in the ecosystem, as Vulkan is very low-level and GLSL is a
primitive language for writing compute kernels (though it can be done in
theory).

I think the OpenCL people get that, and have listed clvk and clspv on their
roadmap. That gives considerably better options for actually running compute
workloads than crossing one's fingers and hoping that the GPU vendors will
implement the spec out of a sense of pity for the spec writers. Another
similar project I learned about recently is vuda[1].

Another project to watch closely is JAX/MLIR, which promises to run Tensorflow
workloads directly on Vulkan. In that ecosystem, it's not clear at all what
value an OpenCL layer would add.

I have a blog post in draft about very fast prefix sum running on Vulkan,
thanks to a comment from fluffything in response to my GPU talk (could you let
me know how you would like to be attributed)? I finally got it to within 10%
of memcpy bandwidth over the weekend, so I'm going to declare victory and
write it up.

[1]: [https://github.com/jgbit/vuda](https://github.com/jgbit/vuda)

------
skohan
I'm not sure if I understand what the value of a new OpenCL version is
precisely. Is there anything you wouldn't get by just adding support for
OpenCL programming language to SPIRV cross and executing kernels with Vulkan
like any other compute shader?

~~~
elbows
One issue is that the Vulkan API is absurdly low-level and verbose. There are
good reasons for this if you're writing a game engine, but if you just want to
run simple compute kernel you're looking at ~500 LoC, probably an order of
magnitude more than with OpenCL. So the barrier to entry is really high.

It also seems the Vulkan supports a different variant of SPIR-V than OpenCL,
with the result that some OpenCL C code can't be compiled to work with Vulkan.
[1]

But it does seem like a combination of lifting Vulkan compute restrictions and
building compute-oriented APIs on top of it could be a better path forward.
Especially since this new version basically seems to be giving up an getting
vendors to support the features that would make OpenCL competitive with CUDA.

[1]
[https://github.com/google/clspv/blob/master/docs/OpenCLCOnVu...](https://github.com/google/clspv/blob/master/docs/OpenCLCOnVulkan.md#opencl-
c-restrictions)

------
fluffything
> Originally birthed by Apple and broadly adopted by the industry as a whole

Do Apple and NVIDIA have good support for OpenCL ?

EDIT: From the same article, further below:

> Apple has deprecated OpenCL

> AMD’s OpenCL drivers are a mess,

> NVIDIA’s interest is tempered by the fact that they already have their very
> successful CUDA API,

~~~
jai_
Apple has officially deprecated the use of OpenGL and OpenCL on it's hardware
since MacOS 10.14 but maintains the implementations for continued use for now
as they would like everyone to use their own Metal API. They are pinned at
OpenGL 4.1 and OpenCL 1.2.

OpenGL and OpenCL are still very mich supports by Nvidia and other GPU
manufacturers, dependent on the OS.

[https://support.apple.com/en-gb/HT202823](https://support.apple.com/en-
gb/HT202823)

~~~
Joeboy
So IIUC this announcement is actually "We're going back to the last version of
OpenCL that actually has cross-platform support". Which makes it seem a bit
less crazy.

------
jeltz
Would it make sense to add support for more compute stuff to Vulkan instead
and move towards only having one framework which supports both compute and
graphics, or are the tasks different enough for it to not be worth it?

~~~
jfkebwjsbx
This would have been way better. Khronos could provide a library on top of
Vulkan to make things easy to use for users and easy to implement for vendors.

------
pjmlp
So basically, anyone that wants a modern language agnostic API for computing,
with SDK and graphical debugging support for C++, Fortran, Haskell, Julia,
.NET, Java, Python, should just keep using CUDA, business as usual.

Because with the reset to OpenCL 1.2-derrived specification good luck with
SYCL adoption, let alone anyone caring to write SPIR-V backends.

~~~
VHRanger
Except CUDA is proprietary and doesn't work on iGPUs and non-nvidia GPUs?

~~~
belval
This is a fair point, but it isn't really a problem for most people. Nvidia
GPUs aren't much more expensive than a matching AMD GPU for
students/researchers.

Once you get in the entreprise market, Nvidia is simply killing it with their
low power consumption and low profile cards (P4/T4) so it usually isn't a
problem and no one really care for the price difference.

~~~
cesarb
The parent comment mentioned iGPUs, which are commonly found on laptops or
small computers like NUCs. If you're a student with a laptop or a NUC, "buy a
new GPU" is not an option; you'd have to buy a whole new computer (and monitor
if what you had was a laptop). That's a high barrier to entry.

~~~
pjmlp
Not if they had an optimus to start with.

Also Intel GPUs just suck at everything that isn't doing 2D GUI acceleration
anyway.

~~~
jfkebwjsbx
Intel GPUs are actually quite good for what they are, even for 3D.

Not everything is AAA games.

~~~
pjmlp
I though we were talking about high performance APIs here.

~~~
jfkebwjsbx
You can run Vulkan on Intel GPUs just fine.

(Unless there are recent issues that I am unaware of, I don't follow why the
mix between hardware and API).

------
Jonnax
So if someone wanted to get into GPU computer what's the best way?

Is it CUDA? openCL1.2? Vulkan has some compute stuff, would that be good
enough?

~~~
pjmlp
CUDA definitely.

NVidia acknowledged early on that you wouldn't necessarly want to use C on the
GPU, and moved CUDA into multi-language support.

So while CUDA C++ is the leading language, you can make use of Fortran, Julia,
Haskell, .NET, Java, Python as well.

You also have very nice graphical tooling for GPGPU debugging, where you can
debug your shaders just like any other application.

You can go through the GTC 2020 videos, [https://www.nvidia.com/en-
us/gtc/session-catalog/](https://www.nvidia.com/en-us/gtc/session-catalog/)

~~~
adev_
> So while CUDA C++ is the leading language, you can make use of Fortran,
> Julia, Haskell, .NET, Java, Python as well.

Outside of the marketing, 99% of CUDA program are done in 'C++ CUDA'.

~~~
pjmlp
GTC 2020 had a bit more than 1%....

------
Joeboy
Over the weekend I dipped my toes into the GPU compute waters a bit, tried to
get to grips with the massive tangle of competing and co-operating
technologies, and tentatively concluded that OpenCL was probably as good a
place as any to start learning, in 2020.

Interested to hear opinions on whether that was a reasonable conclusion, and
whether this makes a difference to it.

~~~
skohan
It depends what you need to do with it. If you're doing something like image
processing or dealing a lot with matricies/linear algebra, Vulkan's compute
support is quite good and the compatibility story is great, but GLSL/HLSL
might not be ideal depending on your use-case.

~~~
VHRanger
Except Vulkan is a giant pain in the ass to set up.

Just getting through the Vulkan tutorial is a weekend long affair.

~~~
whatshisface
Surely once one person has gone through the Vulkan tutorial, everyone else can
copy them?

~~~
pjmlp
No, Vulkan follows the learning path of OpenGL.

Instead of having a nice SDK like the proprietaty APIs do, you are expected to
go hunting for books and online tutorials about third party libraries so that
you can go through all basic steps of loading shaders, textures, font files,
gui frameworks and display something.

Also in the process you will implement your own scene graph and material
support.

Consider it the rite of passage into Khronos' land, which every graphics
programming student throughout the world has to go through.

Yes, there is LunarG SDK, however it is quite anemic versus what VS +
DirectXTK, XCode + MetalKit, PS4 SDK, Switch SDK offer as out of the box
experience.

~~~
jfkebwjsbx
If you really want to understand what is going on, those SDKs are useless at
best, though.

They are fine to get some complex features working specially early on, yes,
but not for learning.

~~~
pjmlp
Yet that is one of the biggest complains in the latest Vulkan survey, lack of
support for learning.

Those SDKs allow plenty of wanna be game developers to just be doing rotating
cubes in less than a couple of minutes and go from there.

Sit in a room trying to go through NeHe tutorials and watch students
motivation slowly fade away.

~~~
jfkebwjsbx
It depends on what you are trying to achieve. If you are trying to teach
gamedev, then I agree it is a pain. However, if you teach a general graphics
course in a CS curriculum, then the slow, spec-like approach is way better.

Regardless I never liked the NeHe tutorials for some reason. I did them when
fixed pipeline was a thing and they bore me a lot, yeah... but when I learnt
modern GL properly it was way better. Seeing a cube rotate is irrelevant to
motivation as long as you understand what you are doing, in my experience.

------
hyperpallium
The complete title was more informative: _Khronos Announces OpenCL 3.0:
Hitting the Reset Button on Compute Frameworks_

~~~
cm0000cm
and echoing a comment above, it's basically: "We're going back to the last
version of OpenCL that actually has cross-platform support"

~~~
pjmlp
Some cross platform, it was never supported on Android, and most likely never
will be.

~~~
cm0000cm
OpenCL is available in pixel 3 and pixel 4 phones, but I agree you can't count
on it for all Android devices

~~~
pjmlp
If it isn't documented in
[https://developer.android.com/](https://developer.android.com/) it doesn't
count.

Using OpenCL custom drivers from OEMs requires ADB shell access and deployment
of custom libraries, hardly something that any application on Play Store can
count on.

------
Rochus
_If a vendor was happy with OpenCL 1.2 but wanted a couple of extra 2.1
features, for example, then to be compliant with the specification they’d need
to implement the entire 2.1 core specification_

Right; from that point of view OpenCL 3.0 is a good move; also IEEE should
consider such a strategy with SystemVerilog.

------
edwintorok
Mesa still hasn't implemented OpenCL 2.x ... now they don't have to. Although
applications like Folding@home don't really work with OpenCL as provided by
Mesa, so it'll likely have to be updated to work with the 3.0 ~= 1.2 version.

------
falldrown
I hope someday they add OpenCL <-> CUDA direct interop (not through
OpenGL/DirectX interop API)

