[robbies]

"I wonder if that's intentional on NVIDIA's part."

I think that's a reasonable guess. NVIDIA only supports OpenCL 1.2 (and it took them about 6 years to get there from 1.0, while other vendors were at 2.x).

While I don't think NVIDIA ever outright stated OpenCL was on the back burner, their support clearly waned, which devs noticed (https://streamcomputing.eu/blog/2012-09-10/nvidias-industry-...).

As for why...well, why should NVIDIA participate? They don't have anything to gain when they already have CUDA dominating the industry.

[intoverflow2]

> They don't have anything to gain when they already have CUDA dominating the industry

Everyone working in it seems to agree there are good reasons for it dominating. Just easier to work with overall.

[dom0]

In the long run every monopoly hurts badly. Puzzling that people think it's good for GPGU, with the x86 fiasco next door.

[hvs]

(Most) people don't make decisions based on overarching theories of what's good for everyone. They need to solve a problem as easy as possible and most people feel that CUDA is easier to use than OpenCL. Plus, NVidia has been a leader in this space.

Also, this isn't a monopoly, OpenCL exists.

[jacquesm]

And given that CUDA is essentially free and you simply pay for the hardware it is actually not such a bad deal. Economies of scale are such that if you can run your workload on gaming hardware you're going to get incredible performance for very little money.

[p0nce]

NVIDIA will prevent you to buy gaming hardware and push you into buying the 10x more expensive ones.

There are 2 NVIDIA drivers. It turns out pinned memory transfers are 2x faster with the Tesla driver (vs the Geforce driver). This can matter a lot for some workloads. For some reason you can't use the faster driver with cheap consumer cards.

So, in my view NVIDIA is dumbing down performance for OpenCL and CUDA alike, and also slowing down the unavoidable OpenCL adoption.

[shaklee3]

Source?

[dom0]

Making decisions and thinking what's good for the ecosystem are two different things. I can still buy nVidia for my company, and think and say at the same time that it's bad.

Of course, while it's the cheap consumer garbage ^W^W pro-gaming hardware, the prices are okay, since these are kept in check by AMD. Once we get to the relabelled consumer garbage ^W^W^W professional compute hardware, you pay for it. Dearly. Why? No one that keeps them in check through competition.

[munchbunny]

For the uninitiated, could you explain what you mean by "cheap consumer garbage" and "relabelled consumer garbage"?

[jjn2009]

Its pretty easy to slap a new label on a card and call it enterprise. Consumer cards can be kept from eating the enterprise sales by creating artificial barriers around what you can do with each line of card.

[cptskippy]

He's referring to the fact that the GeForce line of consumer grade GPUs and the professional line of Tesla HPC Compute cards are probably using the same silicon.

[wohlergehen]

Presumably the Tesla cards, which are targeted at mostly simulations/HPC and enterprise. These tend to start at around 3K a piece.

[amenod]

Not OP, but my guess would be he meant GTX 1080, Titan & co. I would bet the difference in price in comparison to GTX 1050 doesn't come from increased manufacturing costs.

[robbies]

Even if the users acknowledge it is bad to keep using NVIDIA (and allow them to continue domination), what are they supposed to do?

From my view, it's not just that CUDA > OpenCL. Rather, it's CUDA ecosystem >>> OpenCL ecosystem. The tools, the libraries, the documentation, the community - all of these are superior on the CUDA side. If you give all those up to use OpenCL, how do you make up for that cost?

[josefx]

I once tried to use OpenCL when I was still a student. The only Linux support for my Intel GPU I could find aborted various calls with "not implemented".

I am sure their Windows driver actually worked. However that still meant that for my hardware OpenCL was about as portable as CUDA. Just with a Windows lock-in instead of a NVIDIA lock-in.

Edit: Just to note this was a few years ago. I have no idea what the current state is.

[bildung]

I tried it last week: OpenCL support for AMD was just an apt-get away in Debian testing, working with the open source drivers.

[josefx]

Note I used Intel as example, not only because that is what I had at the time, but also because it is a notable third party OpenCL vendor. If you associate OpenCL with AMD then you might as well use CUDA on NVIDIA.

[bildung]

I wasn't trying to imply that! Just wanted to state that things have changed and support is pretty good nowadays (for Intel GPUs, too, BTW, I just have never personally tried those).

[thomastjeffery]

A few years ago, we didn't have AMDGPU. That represents a huge change in the open driver landscape.

It's not perfect, but it's already quite good, and improving rapidly.

[vedranm]

If you are interested in following/contributing to OpenCL in Mesa on AMDGPU, I suggest starting from this bug: https://bugs.freedesktop.org/show_bug.cgi?id=99553

[oneshot908]

Sure, but nothing's stopping AMD and Intel from enabling CUDA on their processors. I personally think NVIDIA has vastly overinvested in Deep Learning at the expense of starving existing and potential other markets, but that doesn't make me want to code in OpenCL, it makes me want to run CUDA elsewhere.

[ris]

I'm pretty sure there is, given that there is now a precedent in the US for an API to be copyrightable following the Java verdict.

[oneshot908]

For now at least, NVIDIA is too busy harassing customers and vendors who build servers based on GeForce instead of Tesla GPUs. Because while they've been hopping up and down with faux outrage, AMD embarked on just such an effort:

https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

So when is Intel going to join the party?

[virmundi]

Is it true that monopolies necessarily hurt? Look at YKK, pretty much a monopoly. Were for years. But when you really had to go, you could count on the zipper (unless is froze, which case buttons are better).

https://www.intelligentinvestor.com.au/2012/07/ykk-the-zippi...

[IBM]

I'm 90% sure this is why Apple hasn't used Nvidia GPUs in years. That and AMD is obviously thirstier and would offer better pricing.

[blackflame7000]

It might hurt the consumer but it doesn't hurt the one holding the monopoly (nvidia in this case). It would be like Microsoft actively working to port their prized game Halo (Nvidia GPUs) to the PS4 (OpenCL) when they already have a perfectly good platform on the xbox (CUDA) which they happened to create as well.

[azinman2]

I know it's besides the point, but isn't the Xbox running AMD gpus (and cpus)?

[blackflame7000]

Yes I believe so. I flipped hardware and software in my analogy to make it fit. You can restrict hardware to only run specific software just like you can restrict software to only run on specific hardware. The point is all about incentive to open your platform to competitors when you are already the leader in both.

[intoverflow2]

I agree 100%, so I waited and waited and waited and waited.

Then I got tired of waiting 4 years for any of the GPU computing software I was interested in to support it and bought an Nvidia GPU and a PC to run it instead and became part of the problem.

[usmeteora]

not to mention SPIR-V integrates OpenGL with Vulkan and and for OpenCL, moving towards a broader range of language support outside of mere wrappers including but not limited to even Javascript.

Since SPIR-V allows you to effectively define your own Shader APIs, and OpenCL has more and more bindings with other platforms, including ones that support the web like Go, Javascript and a new support layer for WebGL, it is absolutely a game (no pun intended) for Nvidia to lose in the longrun.

When has a monopoly never not been caught frantically trying to buy out knockoff companies that spawned from teams developing on opensrouce alternatives in innovative places after they became comfortable and confident with being a closed source monopoly?

On top of this, graphics programmers, the games industry and advanced web support, especially now that AWS and I think google cloud integrate server hosting with GPUs (and companies like Blazing DB for easier integration) will only exponeniate the rate of advantage opensource has since this is a race with some of the best programmers in the world, with a ton of money behind it.

I am curious what NVIDIAS end game is here. Already they were trailing behind the after party with their releases post AMD Ryzen, and I havn't heard anything at all exciting on NVIDIAs part to counter since the Vulkan release and SPIR-V integration announcements, which are some of the most promising I've seen yet, and expansive for programmers who have otherwise avoided this platform due to the extremely indepth learning curve and requirements to be somewhat experienced C/C++ programmers.

It took me 8months to be able to write a good kernel and some good host code with opencl because I did the entire integration in C and C++ and I've been developing with it since 1.2, but with more languages a broader range of support applications, perspectives and contributions will go to the opensource dev.

So far, outside of currently dominating the industry and embedding some long term runway with large contracts and having a head on red tape involved with larger corporations they have contracts for hardware and support embedded with, I don't see what advantages NVIDIA is getting the industry excited about in the long run.

When it comes to savvy programmers in Silicon Valley, a friend of mine who works as a PhD programmer in Deep Learning with Google Scientists did an unofficial ad hoc poll on her twitter, asking people why so much opencl hate and so much CUDA in the valley? There were lots of responses from lots of people, but I only saw on repeated reason over and over again, the initial learning curve is lower with CUDA and its more convenient. There were no specs of performance advantages in discussion.

In the functionalities I apply OpenCL to, CUDA doesn't even offer the same functionality, and in many ways processes algorithms by simply parsing out algorithms CPUs utilized, but OpenCL never assumed this as an optimal path, and reconsiders the entire structure of the algorithm and data its working with, often times reorganizing formats for processing entirely different from CPUs that NVIDIA incorporates as a default.

It's more work to learn than CUDA, but the advantages are worth it in my experience so far.

As a last consideration, When it comes to NVIDIA trying to make their products compatible with OpenCL and OpenGL, I predict that promise of that to be delayed at best, as it took NVIDIA 5 years to make their hardware std OpenCl 1.2 compatible. Vulkan is extremely large in terms of the source code, and SPIR-V is nontrivial, OpenCL is standard 2.0 now, so if getting OpenCL 1.2 was hard for them to integrate in under 5 years, we can expect a lot longer given the new releases.

The learning curve is now going away with the recent releases, so whats the next step with NVIDIA? Good question. The only advantage they seem to have is that they have an advantage right now, but that becomes circular and perhaps backwards going forward.

This strangely reminds me of Microsoft getting ubuntu to run in a Windows partition checksum for checksum, to offer cross compatibility with other operating systems as an advantage to stay competitive in the demographic that produces the most advancement within their own industry.

[p0nce]

OpenCL is being hampered by past perceptions. I think it's absurdly underrated. The newer OpenCL is as easy to get into (with eg. the Intel SDK), conceptually easier (compiler is in memory, one way to do things instead of two APIs) and opens a broad range of hardware.

[llukas]

> In the functionalities I apply OpenCL to, CUDA doesn't even offer the same functionality, and in many ways processes algorithms by simply parsing out algorithms CPUs utilized, but OpenCL never assumed this as an optimal path, and reconsiders the entire structure of the algorithm and data its working with, often times reorganizing formats for processing entirely different from CPUs that NVIDIA incorporates as a default.

Can you explain what you mean? Reads like gibberish.

[usmeteora]

Sure sorry for the delay. With Sparse Matrices, CUDA utilizes the same compressed CSR txt format, and compression form on its chip, that CPUs do. They use the same compression format, but NVIDIA takes some of the parsed squares and just parallelizes the computation on GPUs and saves the zero values in memory to throw in at the end of the computation, which is still a fine way to do the computation, and utilizing GPU performance over CPU performance, but it never redesigned the CSR compression intake format.

OpenCL does something similiar with the null values, but redesigns the entire compression format reading in matrix data and the entire computation of accessing the tiles of data differently based on the format they have for parsing and accessing the data.

I am trying to find a good explanation online, but I can only find what I have in the OpenCL 1.2 Book Chapter 22 on SPMV, where they visualize and explain CUDAs format, and then OpenCLs format, and provide performance comparisons between the two methods using the standard 22 matrix sets provided by the University of Florida.

OpenCLs performance was better on every metric, the smallest increase in performance cutting computation time by one half, the rest were closer to a third. They ran their own CUDA testing, but also provide the whitepaper results from CUDAs testing, and use NVIDIAs reported results as their official comparison.

For an influx of repetitive real time data reading in millions of data points every few seconds, this kind of advantage is not of a negligible significance.

It took a long time to work with but of course now I can reap the benefits every few seconds on large datasets forever so I found it worth diving into the performance specs on this case.

While I cant find an online visual of the designs for CUDA vs OpenCL explained in CH22, the source code for the std SPMV I speak of here is on one of the authors github: "bgaster" is the username. You should be able to download the code working cross platform and read in matrices of your choice, and compare performance on your own if you have datasets you want to look at.

The OpenCL book I highly recommend. It explains how to use opencl and provides comprehensive examples, walking through concepts with code for 22 chapters. The source code for that book is there with the rest of bgasters stuff. It's definitely not a trivial language to take on. The learning curve is steep. However, I learned GPUs through OpenCL, so I don't know if it would be easier coming from CUDA, biases about what to expect because the learner is already reaping the benefits of CUDA aside.

I took time initially to read through the entire 1.2 openCL API over a couple of weeks. It's one of the most comprehensive and detailed API's I've ever read and I find myself dissapointed with documentation of other groups in comparison. Once you are familiar with the scope of functionality available to you, I typically keep the PDF API open and search F for concepts and find whats available to me as I code through things. The most recent API is just as good and can be found here:https://www.khronos.org/registry/OpenCL/specs/opencl-2.2.pdf

Also, one of the authors of OpenCL works fulltime at Apple now, and opencl comes installed and simply working on any OSX operating system. So if you happen to have a mac, it should be relatively easy to download some working source code and try out.

I have OSX, and was also able to download an SDK for my NVIDIA graphics card on an asus zenbook running fedora 24, and got it up and running just fine in an hour or so, for total install and testing.

[unsigner]

What x86 fiasco?

[dom0]

Intel pricing and performance increases since AMD went away (but it seems to be coming back now, so that's good - and indeed, Intel already cut prices in some segments).

[usmeteora]

but other than its easier, are there any performance benefits?

I think the whole point of Vulkan and particularly SPIR-V, was to offer support for broadened languages including but not limited to Javascript.

OpenCL even has go bindings now.

SPIR-V allows you to define your own SHADER APIs.

Right now, it's alot to learn, but going forward, it hard to ignore the advantages in the functionalities and the broadened support to lower the barrier for learning by increasing the number of languages you can work with OpenCL in, particularly ones that predominately support web dev as we move to cloud developing and hosting AWS and Google Cloud with GPUs.

The cloud is a big one here to consider for potential shift in market share because if one group hosting the cloud finds OpenCL to be particularly beneficial, all they have to do is offer support ontop of a stack like Blazing DB, which I imagine a GPU server support stack will be engulfed within cloud platforms backend within 5 years anyways, and suddenly thousands and thousands of companies rely on it and it becomes and industry standard.

The shift in a market where cloud hosting exists on GPUs, becomes more based on what large companies who have the money and talent to go in depth and scale out support for OpenCL based functionalities moreso than the barrier every single developer or hip web dev hosting on the cloud is wanting to overcome to invest in low level kernel writing and hardware optimization.

Throw the games industry in with Vulkan, with opensource games on PCS always competing with console based games, and I see alot more support in the long run with OpenCL.

[robert_foss]

You're implying OpenCL being broken somehow.

Is it broken in any way?

[bostonpete]

I don't see how "easier to work with" implies "broken".

[apetresc]

The GP was saying CUDA was "easier to work with", not OpenCL. OpenCL's broken-ness then presumably is that it's hard to work with.