> NVidia is not to blame if the competition is stuck using C, printf debugging for computing shaders, cannot make their minds about which bytecode to support for heterogenous GPGPU programming.

I don't bite this argument.

Nvidia made close to no effort to support OpenCL and promoted their own technology CUDA. Even in 2020, OpenCL support for Nvidia hardware is close to nonexistent.

When the main actor of the market does not support a technology, why the hell would you use it or even develop its ecosystem (SYSCL)

> The situation is so bad that OpenCL 1.2 got promoted to OpenCL 3.0 and SYSCL is now backend independent.

OpenCL 3.0, presented by an Nvidia official(https://khr.io/ocl3slidedeck), head of the working group on it. A company that made close to 0 effort to support OpenCL 2.0 revert the spec to 1.2. Astonishing right ?

OpenCL isn't also supported on Android, where Google pushes Renderscript instead, their own C99 dialect, yet I don't see any uprising against Google.

If the 139 member companies (taking NVidia out) listed here aren't able to provide the same quality in hardware, programming language and eco-system improvements against those from NVidia, and vote for a NVidia employee as chairman, then they deserve what they get.

https://www.khronos.org/members/list

It is so easy to find a villain instead of acknowledging failure.

OpenCL used to be supported on Android (But not required on by Google). Currently, Vulkan _is_ required by Google[1] and is probably the future path to GPU compute.

[1] https://www.androidpolice.com/2019/05/07/vulkan-1-1-will-be-...

OpenCL is only supported via hacks to install shared libraries into one own's device.

Vulkan even if optional until Android 10, it is supported by the SDK since version 7, which is something that OpenCL never had.

No serious Android developer would make their life even harder than it already is with the official APIs, by making use of an API that requires device owners to manually install libraries via ADB.

Hmm, is the OpenCL situation really that fringe on android? Eg this OpenCL info app[1] description says "Even though OpenCL™ isn't part of the Android platform, it's available on many recent devices. On Android it's usually used as a back-end for other frameworks like Renderscript. Some manufacturers are providing SDKs for developers to use OpenCL™ on Android. "

I addition to the mentioned PowerVR and Intel platforms there seems to be Android OpenCL also for Mali and Adreno GPUs.

[1] https://apkpure.com/opencl%E2%84%A2-info/com.xh.openclinfo

Yes it is, it is not exposed via the SDK, regardless how Renderscript ends up being compiled to machine code.

You won't find any reference to OpenCL here,

https://source.android.com/

https://developer.android.com/

So while those SDKs do exist, they aren't for application developers, rather for OEMs themselves.

You as application developer have zero control about what GPUs the customers might be using, there is no way to control it on Android manifests, only to specify what APIs are expected, which again, don't have OpenCL as part of the list.

https://developer.android.com/guide/topics/manifest/manifest...

So if you as application developer want to use said SDKs, it is only for your own device, most likely rooted, don't expect to sell applications on the store using OpenCL.

Yep, you can't of course rely on OpenCL support, you have to provide a fallback. But are there any issues with including the SDK supplied OpenCL ICDs with the APK, for use with validated GPUs?

Yes, that is not how Android works.

You are not allowed to ship drivers like that, and since version 7, there is kernel validation about stable NDK APIs.

So yeah just because there is an OpenCL SDK for Mali, doesn't mean that a random Android device with Mali will have the drivers or kernel support in place, because that isn't something that Android requires.

Google has collaborated with Adobe in porting their OpenCL shaders to Vulkan.

If they actually cared, they would have made OpenCL available instead.

I see, thanks for the explanation. Oh well, let's see where things go with Vulkan compute.

> I don't bite [buy] this argument.

I don't think NVidia's half-hearted support for OpenCL has anything to do with the argument at all.

It's a really good point that other tool vendors haven't stepped up and provided modern development tools for OpenCL (or any of AMD's various attempts), while NVidia has great dev tools.

It's not about blame. It's about getting to an ecosystem where GPGPU is used for things beyond deep learning, bitcoin mining, video encoding, and similar niche applications to one where I can fluidly use MIMD to speed up my JavaScript and Python with first-class language constructs to support that.

If that happens:

1) We'll get back on some kind of curve where computer performance starts increasing again.

2) The GPU will become more important than the CPU, and the market will explode.

Until that happens, the GPU market will be for gamers, video editors, and machine learning nerds.

I don't much care who does that, or why it hasn't happened.

It is easy to talk about the proprietary practices done by NVidia, yet none of the other GPGU device makers that are on Khronos weren't able to offer a better experience.

So Khronos has 140 members, about 10 of them producing hardware, and they can't provide a proper developer experience, with software that looks like EE toolchains of the 90's.

The market has already exploded, and CUDA has won.

You're missing the point, and taking everything as an attack on NVidia. It's not an attack on NVidia, or have anything to do with Nvidia versus Khronos. It's clear you've got enough baggage there that I won't go there (not like I was trying to go there in the first place).

But the market hasn't exploded. Most computers have built-in Intel graphics, and most apps can't make use of GPU. NVidia won the battle with AMD, but lost the battle with Intel. GPUs are still for gamers, deep learning applications, bitcoin miners, video editors, and a few other niche applications.

Given that CPUs aren't increasing in speed, and GPGPU is failing to make in-roads, for most workloads, computers are only marginally faster than they were a decade or two ago. If GPGPU made inroads into general computing, we'd still be on a Moore's Law curve, but that hasn't happened.

That's the problem.

Not at all, my complain is the poor service that Khronos keeps doing pushing their half backed supported APIs, expecting that OEMs pick up the tooling part.

What ends up happening is that OEMs, coming traditionally from the EE and embedded mindset almost never provide any tooling worthwhile using.

This is why platform APIs always end up winning the hearts of most developers that aren't into FOSS mindset.

Interesting that you mention Intel, they would rather have you using Open API or ispc, instead of pure Khronos APIs.

And Intel keeps failing at their GPU story anyway.