From yesterdays driver release (381.65) (Release notes). Exact same text as from the 378.66 driver from February.
Balance: Interesting. But - it sounds like itâs merely about grid dimension options rather than proper features.
Streamcomputing tested 2.0 features:
- driver 378.66 for Windows - https://streamcomputing.eu/blog/2017-02-22/nvidia-enables-opencl-2-0-beta-support/
- driver 378.13 for Linux - https://streamcomputing.eu/blog/2017-03-06/nvidia-beta-support-opencl-2-0-linux/
about âleadingâ opencl support by nvidia: https://streamcomputing.eu/blog/2012-09-10/nvidias-industry-leading-support-for-opencl/
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).
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 :-)
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.
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.
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.
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.
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?
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.
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.
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
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 :-)
I am hesitant to further pursue an off-topic discussion about OpenCL in a CUDA forum.
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).
Personally, I have considered OpenCL technologically redundant from day one, but then I am strongly biased :-)
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.
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.
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.
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.
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.
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.
OpenCL being suppressed by NVIDIA and Apple
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.
No mention of Google? :-)
I wasnât developing for Android anything bigger than one-day project.