Khronos Announces OpenCL 3.0 | Hacker News Reader

Khronos Announces OpenCL 3.0

anandtech.com

86 pointsXzetaU8120 comments

>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..

> CUDA can now easily compile it to target NVIDA and AMD GPUs, as well as x86-64 CPUs

Are these solutions "legal"? I.e. is there a risk NVIDIA can crack down on tools like this from an IP standpoint if they want to at some point in the future?

IANAL, but:

- NVIDIA themselves ship multiple CUDA to multi-core x86-64 compilers for different programming languages CUDA C/C++/Fortran

- AMD has been shiping hip for a while, advertising it as production ready, without any lawsuits (AFAIK). hip is also being used in production.

- LLVM and clang have had open-source CUDA (and PTX) support for years, and nvidia have not enforced any kind of patents there.

That clang/LLVM support was contributed by NVidia.

I think it was contributed by Google.

The original version of the NVPTX backend was contributed by nvidia, but iiuc they abandoned it afterwards and I think all the work on it since then has been by Google.

> AMD has been shiping hip for a while, advertising it as production ready, without any lawsuits (AFAIK). hip is also being used in production.

Hip is not Cuda and even remove most mention if cuda from its API. It just mimic cuda API to try to provide compatibility.

And the result is that almost nobody use it today.

How do people do GPGPU on AMD today? Because I thought AMD has a huge cloud GPU market share for things like ML

> How do people do GPGPU on AMD today? Because I thought AMD has a huge cloud GPU market share for things like ML

ROCm and HIP [^1] or OpenCL.

OpenCL is the hated solution of GPGPU. It is low level, incomplete and definitively not with a mature ecosystem of tools like Cuda. But it is currently the only one existing if you want your program to run on something else than Nvidia GPU ( Meaning AMD, Intel, phone GPUs or FPGA accelerators).

[^1] https://github.com/ROCmSoftwarePlatform/

Android phone GPUs only do Renderscript, OpenCL is not officially supported on Android.

AMD has a tiny market share in the cloud GPU market. AWS, Google Cloud, and Azure all have compute instances with NVIDIA GPUs, and I don't think any with AMD GPUs (IIRC Azure maybe has windows instances with AMD GPUs for graphics).

According to https://www.techquila.co.in/nvidia-cloud-ai-gpu-share/, AMD is at ~1%.

Can you patent a formal language or API calls ? That's a real question.

I'm sure NVIDIA IP includes the CUDA trademark, their own compilers, SDKs and so on... but the language itself ?

It's a gray area and currently being litigated. If Oracle prevails, then NVidia absolutely would be in a position to shut down compatible implementations of CUDA, or dictate the terms under which they might or might not be able to continue to exist.

Using open standards avoids this risk, though some companies are unwilling to work with Khronos, citing (not publicly detailed) legal concerns.

[1]: https://en.wikipedia.org/wiki/Google_v._Oracle_America

I just want to be able to install a program or library, like Tensorflow, and have it work on my GPU whether it's from Nvidia or AMD without having to first find and install the right compiler.

How do I run a Python program that imports Tensorflow on my AMD GPU today?

That's something you need to ask to your package manager. Making sure that all dependencies of a package (e.g. drivers, compilers, etc.) are installed is the package manager's job.

If you are installing TF from source, then it becomes your job. TF docs should help you here, and TF's build-system should be able to guide you through what you need to install.

> That's something you need to ask to your package manager. Making sure that all dependencies of a package (e.g. drivers, compilers, etc.) are installed is the package manager's job.

No that's bullshit and it shows you never have done it.

Tensorflow is CUDA only and does not run over AMD GPU. Because CUDA is proprietary and has a monopoly on GPGPU for now.

It is such a big deal that AMD had to fork tensorflow and try to make their own version it in order to make it "partially" run over HIP. This naturally makes it behind upstream, buggy and partially updated [^1]

CUDA is not portable and will never be.

The sad truth is that, due to CUDA, a big majority of GPGPU programs are now vendor lock-in on Nvidia hardware. That is unacceptable, but it is like that.

[^1]: https://github.com/ROCmSoftwarePlatform/tensorflow-upstream

> It is such a big deal that AMD had to fork tensorflow and try to make their own version it in order to make it "partially" run over HIP.

That's because HIP requires changes to the program source code, but AMD has managed to upstream those patches to other projects. If they haven't done that for Tensorflow, that's kind of their problem.

Clang can compile CUDA code, and it has an AMDGpu backend. AMD could compile that CUDA code to SPIRV if they wanted. Intel and PGI do compile CUDA to x86-64 using LLVM without problems.

> How do I run a Python program that imports Tensorflow on my AMD GPU today?

https://rocm-documentation.readthedocs.io/en/latest/Deep_lea...

ROCm is only officially supported on AMD Instinct GPUs. For others, it’s a best effort thing only:

“ AMD ROCm is validated for GPU compute hardware such as AMD Radeon Instinct GPUs. Other AMD cards may work, however, they are not officially supported at this time. We appreciate your feedback and we will consider it for future versions of ROCm.”

https://github.com/RadeonOpenCompute/ROCm/issues/887#issueco...

> ROCm officially supports AMD GPUs that use following chips:

> "Vega 10" chips, such as on the AMD Radeon RX Vega 64 and Radeon Instinct MI25

https://github.com/RadeonOpenCompute/ROCm

Right. Because they happen to use the same chip.

But if you’re using the current consumer product line, it’s hit or miss.

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.

Well, now that SPIRV is upon us, we can write a custom shading language which targets SPIRV

You can, the point is who will care to use it, and which graphical tools across the industry will care that it exists.

Hence why Google and Samsung spent about one year doing it for HLSL, and it still isn't 100% compliant with DXIC.

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

Implementation and standardization should go hand-in-hand, to make sure that you don't standardize something that's unimplementable.

If you can't find companies to implement the standard while it's being developed, then maybe nobody cares?

Indeed, just take a look at the slide about which OpenCL version each company is supporting.

>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.

I believe it's because the alternatives are controlled by Microsoft, isnt it?

Microsoft, Apple, Nintendo and Sony.

Contrary to urban myths Khronos APIs have little uptake on consoles, if they are supported at all.

Isn't Vulkan supported on Series X or PS5? That wouldn't surprise me, given every vendor wants to rule with their API.

Series X is DirectX 12 Ultimate, and the PS5 will most likely have another generation of LibGNM/LibGNMX.

Even on Switch there is the option of going with NVN or middleware like Unity and Unreal.

According to Unity official numbers, they have about 50% of share across Switch titles.

Thanks a lot for the answer!

So no Vulkan at all for Series X? Not even planned? That is sad but expected :(

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.

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.

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.

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

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

They have enough customers on XBox ecosystem.

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

If only Vulkan had an SDK half as good.

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

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.

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.

> 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.

What is your argument here exactly? Isn't it one of the stated benefits of Vulkan, that because of SPIR-V as a shader language, developers can choose whatever high-level language they write to implement shaders in?

If developers can target Vulkan without re-writing their shaders that seems like a sign of strength not a sign of weakness.

It is a weakness, because they had to adopt the competition's shading language, as they weren't able to improve their own.

Also in the age of middleware, Vulkan is only a checkbox away, so unless one is writing game engines, it is quite irrelevant.

For example, OctaneRender gave up on the Vulkan backend and replaced their prototype with Optix 7.

I bet no one on the VFX movie industry will care one second about their change.

It's like you didn't even read my comment

edit: just for the record, pjlmp added everything after the 1st line to his comment after I posted this response

I did, not being able to offer something better than the competition is a weakness, regardless of the opportunities that SPIR-V allows for.

GLSL is not part of Vulkan's value proposition and has no bearing on Vulkan's success. The competitive feature which Vulkan offers is it's non-proprietary nature and crosss-platform support. If it can deliver that with the same or better performance as proprietary solutions, and offering developers more choice about which language they want to implement shaders in, this is a clear win for Vulkan.

Honestly the whole thing makes me sick. And now effin Khronos comes up with their 15th grand new idea.

Every party in this is a PoS in once sense or another.

You'd think Khronos would learn from their (many) past mistakes with OpenGL but apparently they seem to miraculously have found some leftover foot left to shoot. I guess hindsight is 20/20 and all that but it's pretty crazy that they seem to miss the mark so reliably over the years.

Nah, just check the Vulkan extensions registry.

Issues

1) Are there issues?

RESOLVED: Yes.

https://www.khronos.org/registry/vulkan/specs/1.2-extensions...

As an outsider reading this, it sounds like OpenGL vs DirectX all over again - an open API is good, but a good API is better.

Alternative take: An Open API is good, but Microsoft and Nvidia are too powerful to allow it

http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-an...

I'm not much of a graphics programmer, so take this with a grain of salt, but from talking to people who are, the impression I've gotten is that OpenGL is stuck in this weird middle state where it still has two ways of doing things, a simple and easy, but inefficient way where you specify everything from scratch each frame, and one where you use more persistent state like vertex buffer objects to minimize copying and speed things up, but the latter has a cumbersome bolted-on-top API. By comparison DirectX only supports the latter, but was from the start designed with a nicer API to deal with this persistent state, so engine programmers tend to prefer it. And rumor has it that it was the CAD companies that were preventing a modernization of the OpenGL API to properly compete with the ease-of-use of DirectX. So this wasn't just a fight of open vs proprietary, it was also a fight of design-by-committee vs single coherent architectural vision.

This isn't really accurate; the immediate-mode approach you're talking about was deprecated in OpenGL 3.0 and was never supported in OpenGL ES, and in fact, Direct3D started out with an immediate-mode API just like OpenGL before moving to retained vertex buffers.

As someone who spent quite a bit of time with OpenGL, this criticism never really scanned with me. Yes there were multiple ways to do things, but it was fairly easy to understand what the modern parts of the API were and just use that subset. If you run through any modern OpenGL tutorial it will explain this very concisely, and I never had an issue being unsure which parts of the API to use.

That said, Vulkan really does solve all of the real pain-points which existed with OpenGL. It’s very well documented and nice to use, and I really don’t understand why anyone would choose a proprietary api over it.

What about a good, open API like Vulkan?

With regards to HIP, here is a quote from AMD's FAQ:

> Most developers will port their code from CUDA to HIP and then maintain the HIP version. HIP code provides the same performance as native CUDA code, plus the benefits of running on AMD platforms.

E.g. AMD wants developers to develop primarily in HIP. The CUDA->HIP transpilation tools is to help developers make the switch.

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

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?

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...

> 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,

Not lately. Apple is deprecating it in favour of Metal and nvidia haven't been supporting well the latest 2.x versions nudging users towards CUDA.

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

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.

You can still use openCL and openGL on Apple hardware through MoltenVK (the former because it compiled to SPIR-V)

No, MoltenVK is only for Vulkan, not OpenGL.

You can port openGL shaders to SPIR-V to some extent.

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?

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.

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.

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

As proven by its adoption, like with 3D APIs, that isn't something that most people actually care about, rather eco-system and tooling.

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.

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.

Not if they had an optimus to start with.

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

> Intel GPUs just suck

Can confirm. 8 bit floats. Yes, really.

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

Not everything is AAA games.

I though we were talking about high performance APIs here.

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).

Still proprietary, but compiles to AMD and x86 now as well as nvidia.

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?

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/

> 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'.

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

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.

~5 years ago I burned myself badly by choosing OpenCL and AMD cards as a compute platform. I expected the OpenCL ecosystem to be at rough parity with the CUDA ecosystem in terms of features and performance. That couldn't have been further from the case. I wound up selling my cards, eating the spread + shipping + 10% ebay fees, and switching teams.

Just bite the bullet and pay the green tax. It's cheaper than your health and sanity.

It's a pretty bad place. Requires a lot of boilerplate, hard to use debugger, and has less features than CUDA.

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.

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

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

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

The problem is that Vulkan's power comes from specificity: in other words you can plan your resources and executions for exactly your use case which gives great performance with little overhead. The trade-off is because everything is so hand-tailored, it's very difficult to generalize, so just copy-pasting an implementation is only useful if you want to do exactly the same thing.

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.

Honestly if Vulkan followed the path of OpenGL it would be about 100x easier than it really is!

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.

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.

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.

Couldn't it be solved with a universal template? Something like bootstrapper for computation applications?

It could be sorted out with a friendly begginers SDK, but Khronos sees that as responsibility for the partners, they just do specs.

But once you get competent it's like having super powers

I think I mostly just want to assuage my embarrassment about being a computer programmer with no idea how to use most of the computing power in modern computers.

Edit: And ideally I'd like to be able to learn on my "Intel Integrated Graphics" laptop, although I don't care about performance there.

Maybe I should be looking into something that can target SPIR-V via LLVM, or something? Don't know what good options currently exist for for that. I'm generally a bit lost, if that's not already obvious.

> ideally I'd like to be able to learn on my "Intel Integrated Graphics" laptop

NO.

Rent a cloud server or buy an old computer with a discrete GPU. Don't even try winging it. This is not x86 land where everything works everywhere. Not even close. NVIDIA/CUDA is what everyone does, AMD/OpenCL is like shooting yourself in the foot, and Intel Integrated / OpenCL is like shooting yourself in the head.

Yes, really. Last time I encountered Intel Integrated, I spent an entire weekend trying to port a relatively trivial shader. It would compile and run, but the output was always very wrong. Needless to say, the tooling was no help, and remember this is GPU land where you don't have printf, but I eventually discovered the problem: 8 bit floats. Yes, 8 bit floats are a thing in Intel Integrated land. No, it didn't give me any warning it was using them. "You asked for a float, you got a float, what's the problem?" I imagine an intel engineer saying. Because I'm a stubborn SOB I didn't learn my lesson there and I soldiered on -- next bug was a silent pageout issue.

Does this sound like fun? If so, go for it. If not, buy a discrete GPU. AMD might be OK these days, they've been working on their problems, but once bitten twice shy, so my recommendation is to buy something with an NVIDIA GPU and consider the green tax an investment in your mental health.

> Yes, really. Last time I encountered Intel Integrated, I spent an entire weekend trying to port a relatively trivial shader.

What are you talking about? What API were you using? I use Vulkan to target multiple GPU architectures and I have never had a problem with compatibility or shader behavior, even with very complex multi-pipeline processes.

In general, if your code doesn't throw validation warnings, it will do what you expect on any hardware.

GLSL. Maybe Intel Integrated works better with Vulkan, but 8 bit floats were a hardware choice. The only way to "support" them would be to throw warnings/errors or kick back to software emulation.

In my experience, Intel drivers are quite good, specially in Linux.

I mean if all you want to do is dip your toe in the water with GPGPU programming OpenCL is probably honestly a fine place to start. Specific knowledge of the OpenCL API is probably not the most useful thing in the world, but you will learn a lot about the basic concepts about how the host and the GPU talk to each-other, and how the constraints of GPU programming are different than CPU programming, all of which will carry over to other technologies like CUDA or Vulkan.

You could also get started with a simple Vulkan compute example, but as others have said learning Vulkan is a task unto itself, so if you're just playing around and you're not sure if you really want to invest in learning it for something valuable, it might be more of a time sync than you're interested in.

> I mean if all you want to do is dip your toe in the water with GPGPU programming OpenCL is probably honestly a fine place to start.

I think really that is all I want at this point. But I'm taking the many dire warnings under advisement. Vulkan sounds a bit hardcore for me right now.

FWIW it’s probably easier to try out an openCL tutorial on your iGPU and see for yourself than it is to provision a cloud GPU or build a new system

While if closed source is a dealbreaker for you, I can understand your conclusion, but otherwise just use CUDA. It is better in simply all the ways that matter, with a simpler API and a lot more resources.

Having to buy a new laptop is a dealbreaker for me, which I think I would have to in order to learn CUDA on it.

You are honestly better off renting a cheap spot priced GPU instance than trying to do anything on a laptop, doubly so if said laptop GPU is not even supported by CUDA.

Otherwise your whole learning experience is going to be an exercise in frustration with almost zero tangible output.

The complete title was more informative: Khronos Announces OpenCL 3.0: Hitting the Reset Button on Compute Frameworks

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

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

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

If it isn't documented in 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.

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.

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.

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

Reply on news.ycombinator.com