OpenCL 2.x support plans?

Accelerated Computing CUDA CUDA Programming and Performance
#21

From yesterdays driver release (381.65) (Release notes). Exact same text as from the 378.66 driver from February.

#22

Balance: Interesting. But - it sounds like it’s merely about grid dimension options rather than proper features.

#23

Streamcomputing tested 2.0 features:

#24

about “leading” opencl support by nvidia: https://streamcomputing.eu/blog/2012-09-10/nvidias-industry-leading-support-for-opencl/

#25

For-profit organizations are driven by economics. Petitions without an economic incentive are therefore likely to have negligible or no effect.

If requests for improved OpenCL support were accompanied by a contractual commitment to buy, say, 1000 Tesla-brand GPUs per year, for the next five years, that might make a difference, approximately covering the cost of development (wild guess on my part).

#26

I agree, and this is very tragic side of companies that pushing their monopoly by suppressing open standards because of economic incentive. And this is in fact exchange of global products development and global researches speed/efficiency for local profits of monopolist (at least in long-term).

And it seems that in 2011-2012 NVIDIA recognized their economic interests by stopping being “Industry-Leading Supporter For OpenCL”.

All efforts in CUDA can be redirected or dublicated for OpenCL, and this also led to economic profit of NVIDIA. Because if you are the only one who has good dev tools like kernel profilers and so on - developers will choose your hardware, and that leads to better optimization for your hardware and so your hardware looks more interesting for final consumers but without this taste of monopoly and with compatibility with other hardware/software solutions, and so everybody are in profit in long-term.

But yes, if company will target to be monopolist - it will have even larger profit, but this is not very satisfactory success :-)

#27

Profits are not a bad thing. They keep companies alive. Look at what happens to companies that do not consistently turn a profit. Look at what happens to their employees. Down sized. Layed off. RIFed.

There is no monopoly involved here. Customers are free to use competing implementations of OpenCL, nobody is forced to use NVIDIA’s implementation. There is no “suppression of open standards”, in fact NVIDIA is a member of Khronos (best I know) which is responsible for the OpenCL spec. Last I checked, every company is free to make their own decisions which software they want to support, and at what level. This is not unique to the graphics market. How many versions of Linux does your cell phone support?

Producing, maintaining, and supporting good software is expensive. For a hardware company to provide a lot of software at no charge to customers only makes sense if that drives hardware sales that significantly exceed the cost of software development. By making good compiler, tools, and libraries, NVIDIA has been trying to create a lot of hardware sales. Seems like a good approach to grow a business, but it requires along-term strategy. After ten years of investing in the GPU compute business, they are now reaping the benefits.

Any competitor is free to make products that rival and surpass NVIDIA’s. That’s competition, and it is good for technological progress. Without competition, we simply would not have compute devices whose performance rivals million dollar supercomputers from not that many years ago (that cost millions!), all for a few hundred dollars.

#28

Of course richer company can spend more money for research, dev tools and libraries. Libraries and tools from NVIDIA are really great, but exactly here you can see that monopoly is being establishing - NVIDIA have no dev tools for OpenCL on their hardware.

NV Visual profiler stopped supporting OpenCL many years ago. It was possible to workaround this, and use it with OpenCL like for CUDA - http://uob-hpc.github.io/2015/05/27/nvvp-import-opencl.html, but not for now, because in CUDA 8.0 (and drivers) COMPUTE_PROFILE env variable support was dropped - you have no profiler for OpenCL!

If you as a software developer want to protect your IP - you can’t bundle original sources for kernels, because they can be easily intercepted on sending to driver for compilation. And this problem was solved in OpenCL long time ago - SPIR (I don’t talk about new SPIR-V, I am talking about good old cl_khr_spir). But NVIDIA doesn’t support it. So even if OpenCL 1.2 (1.1 if you are in 2015) is ok for you - you can’t use it for NVIDIA because this is not safe for your IP, and this exactly looks like “may be you will use CUDA?”

And yes, I know about workaround of bundling ptx assembly (generated by driver) for OpenCL, but I can’t rely on it - what if NVIDIA will disable this feature like it disabled COMPUTE_PROFILE? And compiling of these assemblies requires all GPUs of needed architectures in your buildbots.

When NVIDIA was supporting only OpenCL 1.1 (in 2015) - you were forced to switch to CUDA, because even popcount wasn’t available! (or spend much more time to have special ptx assembly for NVIDIA in your kernels) And this means that for 5 years OpenCL was looking like “you can use it for all hardware, but NVIDIA will work only if you are using OpenCL 1.1, BUT all missed features of OpenCL 1.2 already available for you in CUDA!” And this is exactly the same situation with OpenCL 2.0

So you can use NVIDIA hardware only if you use CUDA, or by investing a lot of time by workarounding all those missed OpenCL-functionality on NVIDIA. And this is exactly what I mean by “pushing monopoly and suppression of open standards”. And this is slowing down researches and developing.

What’s the point of being a member of consortium if you don’t support its standards?

I even don’t talk about “professional” hardware. A lot of people buy them because they were told so, or because of funny reasons like “you just can’t insert geforce GPU into server because power supply joint is from bottom, not from end face”. And this is example of another non-fair competition like with OpenCL. Customers should choose Quadro/Tesla because of their functionality like double-precision support, ECC or TCC. This is exaclty like developers should choose CUDA because of some cool features, but not because 60% of market GPUs don’t support OpenCL 2.0.

Don’t get me wrong, I really respect NVIDIA for great hardware, and for great CUDA dev tools, and for CUDA itself (because it was the first useful tool for GPGPU), but I can’t be loyal to it for now, when I spend a lot of time workarounding weak OpenCL support on NVIDIA hardware or by duplicating all my OpenCL functionality on CUDA just because I can’t use cl_khr_spir for NVIDIA GPUs.

The fair competition is when you support but not suppress open standards, and so users choice based on your hardware functionality or tools/drivers quality.

#29

Fifty years ago, the Rolling Stones made a song about this situation: “You can’t always get what you want”. Your needs and desires and NVIDIA’s needs and desires are not sufficiently aligned. This happens in life, a lot (e.g. every time someone switches employers). I’d be inclined to say: Make a decision and move on.

One interesting aspect of the whole scenario for me is this: Who created OpenCL, and why? OpenCL was created by Apple, an 800-pound gorilla and the master of walled gardens. Why would a company that has “proprietary” written all over it in giant letters, that jealously guards every nook and cranny of their platforms, create an open standard? I think the answer to that question explains (almost completely, as far as I am concerned) the trajectory OpenCL has taken.

#30

Yep, and I am moving on, but I can’t keep silent when you told “NVIDIA doesn’t suppress open standards” :-)

I don’t agree about this implicit conclusion. For now Apple tries to suppress OpenCL exactly the same way - for example they also don’t support cl_khr_spir even for non-NVIDIA GPUs, while drivers for those hardware have support of cl_khr_spir on Windows and Linux. And I believe the reason is “Metal API”. So I am quite sure that OpenCL is a real open standard that is on its own for many years like OpenGL. And it seems that Khronos consortium provides possibility to prevent abusing by standard and NVIDIA as a member can use this possibility. If it is not so - please tell about this. Maybe I should go to Apple forums :-)

A lot of work in LLVM also was done by Apple employees, but are there any problems with LLVM? Many people and companies use it, including NVIDIA.

If there are some problems with OpenCL trajectory - please tell about that explicitly, I am very interested.

#31

Moving on is giving up on changing things. While it’s true that an individual has little hope of changing a large corporation’s mind, public pressure from the user/customer base might do that under certain circumstances. Of course, a forum thread is not that much pressure.


 and presented to the Khronos group/consortium, and adopted, so that OpenCL was a Khronos release. That is, a standard of a consortium of which nVIDIA is a key founding member.

That would be the pot calling the kettle black, there. While nVIDIA is a smaller Gorilla, and the walled part of its garden is smaller, it’s still there. Also, again, Apple proposed, nVIDIA accepted.

I would, however, appreciate it if you could elaborate regarding how Apple has, in your view, distorted the evolution/the trajectory of OpenCL. Specifically, what prevented nVIDIA from bringing essentially all of the features we enjoy in CUDA into OpenCL, eventually bringing the two together enough to just “live” in a souped-up-OpenCL world?

#32

That’s a good question, and I wonder if there does need to be OS support for OpenCL 2.0. Both AMD and Intel have OpenCL 2.0 hardware and toolchains, but OSX doesn’t support OCL 2.0 on either of those architectures even though they’re capable. I do not know if this is because both AMD and Intel have abandoned OSX or if it’s because Apple is passively depreciating OpenCL to promote its own preferred Metal language.

#33

nVIDIA, at least formally, does not wonder. That is, while it’s part of Khronos and has not opposed OpenCL 2.0 in favor of something else. Now, I personally feel OpenCL is kind of clunky compared to CUDA in some ways, but its expressivity is improving with 2.x (e.g. C++ kernel code), so it’s not as though the standard itself is going in a bad direction, right?

So, you’re saying Apple has been artificially delaying OpenCL 2.x support? That is, indeed, underhanded and inappropriate behavior for an important member of Khronos. I wonder who else I can think of who fits that category :-) 
 like I said, a pot-calling-the-kettle black situation.

#34

Not only OpenCL 2.x, but cl_khr_spir extension also, which is very important for IP protection.

Google is also “Promoter member” of Khronos, but it also pushing their own technology (Render Script). It even blocked OpenCL driver in Android 4.3

#35

I am hesitant to further pursue an off-topic discussion about OpenCL in a CUDA forum. I do not know why Apple created OpenCL, but I can speculate. See whether my speculation makes sense to you, or feel free to propose an alternative theory.

My speculation: it all boils down to economics, nothing to do with technology. To maximize their profits, Apple likes to control all technologies they use in their platforms 100%. Their worst nightmare is a new technology controlled by a supplier. They can counter this by proposing a competing open standard that gives them partial control. Other companies sign on to the new standard because it is in their economic interest at that time. For the past five years or so, I have seen little economic incentive for any company (other than AMD), including Apple, to carry OpenCL forward. The consequences are predictable, and exactly what we observe in the market (see comments above).

Note that there are industry consortiums galore, and the reasons for participating in them are varied. However, I would boldly claim that in most cases companies joining such consortiums are not motivated by a desire to actively promote a particular technology, and nobody should have any expectations that they do.

Personally, I have considered OpenCL technologically redundant from day one, but then I am strongly biased :-)

#36

This is another counter-argument for your statement that “there is no suppression of open standards” :-) There is no branch for OpenCL on forum, and no possibility to report bug about OpenCL support (only as CUDA-related bug).

This is interesting opinion and I am interested in reasons for such opinion. Can you elaborate please? Because for me it seems that OpenCL 2.x is equal in possibilities to CUDA.

#37

OpenCL started as a close duplicate of CUDA (in particular, the CUDA driver model), with no particular technological advancement. Created for completely non-technical reasons, I believe, as reasoned above.

For years thereafter OpenCL features lagged CUDA (e.g. C++? Device-side launches?). At this point, I would argue it does not matter what features were added to OpenCL recently, it is on the way out, support is waning.

I do not claim to be deeply knowledgeable about OpenCL, so maybe I missed some break-through technical feature it offers. As a CUDA developer I made sure to always have a firewall between my work on CUDA and anything that was going on with OpenCL.

#38

Open standards are always better for community in long-term. So at least possibility to write code once and run everywhere is good enough reason.

Device-side launches (nested parallelism) were introduced in OpenCL 2.0 (november 18th 2013) and in CUDA it appears in CUDA 6.0 (november 14th 2013). The same situation is with “the most dramatic programming model improvements in the history of the CUDA platform” - unified memory. But C++ seems really be in CUDA earlier. So there is in fact no really major difference in standards - they both look and try to adapt best parts of each other, and this is good.

Yes, CUDA was the first, and many people respect NVIDIA for this, but open standard is better for the world.

I will try to stop spamming :-) But I really spend a lot of time on workarounds because of OpenCL being suppressed by NVIDIA and Apple.

#39

No mention of Google? :-) My take is that many relevant companies are largely ignoring OpenCL now because it does not (or: no longer) serve their business needs. There is no active “suppression” I can see. It is rational disinterest, for economic reasons.

#40

I wasn’t developing for Android anything bigger than one-day project.