[TheCartographer]

Professional GIS user here. Most of my high resolution terrain models are well within the capacity of even a modest GPU to load into WebGL and run on a browser without breaking a sweat. Terrain models are static by nature and don't require a lot of horsepower once they are loaded.

The struggle comes in reading the data from storage, where several minutes can be spent loading in a single high resolution raster for analysis/display. When I built my own PC this year, I splurged on an M.2 SSD for the OS and my main data store. Best decision I ever made for my workflow - huge 3D scenes that formerly took minutes to load on a spinning platter now pop up in seconds.

This thing would probably be the bees knees for what I do. Shame it starts at $10k (and that it's AMD so no CUDA, so no way to justify it at work for "data science" :-/).

[thescriptkiddie]

Any idea why Nvidia dominates in "serious" GPGPU applications? I remember people mocking them for refusing to adopt OpenCL, and when they finally caved their implementation performed far worse than AMDs. How did they win people over? Did they give out a bunch of free GPUs to universities or something?

[kartD]

CUDA mainly. It's fast (faster than OpenCL) and NVIDIA is really good with their software. CuDNN for deep neural networks is almost an industry standard. Nvidia understands software and markets better, while AMD sits on their butts for too long. Granted AMD always come out with a good open source solution that is always just a bit worse and very late. NVIDIA tries to create markets while AMD mess up and end up becoming followers. Shame really.

Edit: this is a good step though. AMD should be pushing the envelope and hopefully with Zen, they can actually realize some of the gains of HSA (which they tried to pioneer but it wasn't so useful since Bulldozer isn't that good)

[hatsunearu]

Shame because AMD seems to pop out cards with higher max tflops but seems to fail hard in the software department

[wyldfire]

CUDA is not [unqualified] "faster than OpenCL". NVIDIA does design software better than AMD, without a doubt. I think it's likely that NVIDIA decided to push CUDA and lag OCL support if their customers balked at having to port between the two. It's not that hard to port IMO, they're extremely similar.

[AIMunchkin]

OpenCL IMO is an ugly API born of the equivalently ugly CUDA driver API because Steve Jobs got butthurt at Jensen Huang for announcing a deal with Apple prematurely. Downvote all you like, but as John Oliver would say "That's just a fact." I witnessed it secondhand from within NVIDIA.

In contrast, OpenCL could have been a wonderful vendor-independent solution for mobile, but both Apple and Google conspired independently to make that impossible (ironic in Apple's case because of OpenCL's origin story and idiotic in the case of Google and its dreadful Renderscript, a glorified reinvention of Ian Buck's Ph.D. thesis work, Brook).

Fortunately, AMD appears to have figured out OpenCL has no desktop traction and they have embarked on building a CUDA compiler for AMD GPUs called R.O.C (Radeon Open Compute). They have also shown dramatically improved performance at targeted deep learning benchmarks. It's early, but so is the deep learning boom.

The wildcard for me is what Intel will decide to do next.

The big win IMO is vendor-unlocking all the OSS CUDA code out there.

https://github.com/RadeonOpenCompute https://techaltar.com/amd-rx-480-gpu-review/2/

[wyldfire]

Jobs might've been butthurt and it might've made better incentive but nobody likes to sole-source critical technology elements.

[AIMunchkin]

It would have been fantastic if Intel had stopped beating the linpack horse a lot sooner and built a viable competitor to GPUs by now. Not this timeline though alas... Maybe 2020?

[ak217]

They did give out a bunch of free GPUs to universities, but more than that, they have invested heavily and deliberately in HPC: community engagement, better SDKs (it's been almost a decade since I've first been able to build a Linux executable against CUDA, and that code should still work), server SKUs sold in the server channel (AMD didn't bother to design SKUs for servers until it was too late). Other things that solidified NVIDIA's lead were the AWS win (in 2010, they managed to partner with AWS to bring GPU instances to market - and those are thriving) and the 2011 ORNL Titan win (important for the HPC community mindshare).

[smhost]

They also partner with universities to design courses around Nvidia products, so they're better at funneling talent. Or at least it seems so. I don't know about AMD programs.

[pjmlp]

Better tooling.

Also they accepted the world has moved on and CUDA accepted C, C++ and Fortran since day 1.

Shortly thereafter they made the PTX Assembly format available and any language could easily target it for GPU execution.

OpenCL got stuck in a world of C with the same runtime compilation model as GLSL.

Only after loosing to CUDA they cave in and created SPIR and the SysCL C++ implementation.

And they have done it again with Vulkan.

While Metal and DX are object based, even the shader languages are C++ like, Vulkan is all about C.

Recently they decided to adopt NVidia's C++ wrapper.

[pcwalton]

I don't know anyone who thinks Metal is better than Vulkan. In fact I've heard only the opposite.

And the reason why it's C is so that you can bind from multiple languages. DirectX doesn't have this problem because it's not plain C++, it's COM--which is designed to support bindings from multiple languages. But COM is effectively Windows only, and Vulkan needs to be platform independent. So Khronos made the correct choice here.

As you acknowledged, they also created an idiomatic C++ wrapper, so I don't see what your complaint is at all. Khronos did the correct thing every step of the way.

[pjmlp]

With the rise of middleware engines on the industry the actual APIs are even less relevant nowadays than a few years ago.

Besides the big studios already abstract the graphic APIs on their in-house engines anyway, or they outsource to porting studios.

Usually the HN community, which is more focused on web development and FOSS, seems to miss the point that the culture in the game industry is more focused on proprietary tooling and how to take advantage of their IP.

The whole discussion around which API to use isn't that relevant when discussing about game development proposals.

It is more akin to the demoscene culture, where cool programming tricks were shown without sharing how it was done, than the sharing culture of FOSS.

If NVidia hadn't made their C++ wrapper available, I very much doubt Khronos would have bothered to create one of their own.

[pcwalton]

> With the rise of middleware engines on the industry the actual APIs are even less relevant nowadays than a few years ago.

> The whole discussion around which API to use isn't that relevant when discussing about game development proposals.

OK, so if the graphics API doesn't matter, why did your parent comment participate in the graphics API war?

(BTW, I agree with you that the graphics API doesn't matter too much anymore. But I think if you're going to attack Vulkan, you should do so based on specific technical reasons.)

> If NVidia hadn't made their C++ wrapper available, I very much doubt Khronos would have bothered to create one of their own.

Khronos isn't a company—it's a standards body. As NVIDIA is a member of Khronos, "Khronos" did bother to create a C++ API.

[pjmlp]

Well, for me being based on pure C instead of the OO interfaces of other APIs it isn't something that makes me wish to use it.

I rather use APIs that embrace OO, offer math, font handling, texture and mesh APIs as part of SDKs instead of forcing developers to play Lego with libraries offered on the wild.

> Khronos isn't a company—it's a standards body. As NVIDIA is a member of Khronos, "Khronos" did bother to create a C++ API.

I guess that is one way of selling the story.

[kartD]

Any opinions you'd like to share about using Metal? I can't seem to find much online about developer's experience with Metal, which seems bad...

[RussianCow]

I think it was a combination of marketing and great developer tools. I'm not in that business so I don't know first-hand, but former colleagues have said that Nvidia provided tons of tools, examples, and resources, while AMD basically completely neglected developers. This is changing now, but at this point it's too little, too late.

[speeder]

As someone that recently switched from nVidia to AMD, I can also say that nVidia products are just plain better.

AMD is trying to fix it, but also now "too late", their drivers, that frankly, are crap, on all platforms, AMD drivers are very, VERY buggy.

Also, AMD GPUs need excessive amounts of power, at first I didn't considered this a problem, until I bought my AMD GPU and noticed it is constantly throttling and causing stutter even in professional software, due to power limits, it also bit AMD in the ass during the RX 480 launch (where the excessive power usage went beyond the motherboard limits, and their "Fix" was make the driver instead request power beyond the specification of PSU cables instead, or allow users on Windows, to enable a harder power limit, making it throttle even more).

I had hope AMD would "scare" nVidia into improving, into stopping their shady business practices and just improve their business, but after actaully buying AMD product, and interacting with their crappy support, crappy community, crappy distribution network (it was very hard to get the card!), I concluded that AMD has a loooong way before they make nVidia react, AMD is too far behind in all aspects, and the only reason they are still competitive, is because they sell very power-hungry beefy GPUs for cheap prices, achieving a reasonable performance per dollar, but if you compare their products ignoring that, they are just junk (both in the hardware and software sense).

[NovaS1X]

You sound incredibly biased, even if unconsciously. I've not had even close to the same experience you have. You even feed into the power draw crap.

[tankenmate]

NVIDIA supports developers better than AMD does (on the whole). So they got CUDA working first, and helped developers get their computational frameworks running on CUDA easier and faster. That gave them several hardware generations of head start. If OpenCL 2.x becomes easier to support and more performant as Khronos claims then maybe there'll be a shift.

[thedaemon]

ATi has always been bad at openGL performance in 3d content creation apps. That's the reason. Back in 2001 Nvidia ranked supreme and ATi was buggy. Seems these days both can be buggy but Nvidia is still #1. The 6800 was a industry changer.

[tankenmate]

Well it will be a almost dead set certainty to run OpenCL, hopefully it will have bindings / extensions to handle the SSD directly from your OpenCL code. Then all you need to do is port the code.

[dingle_thunk]

The dev kit is $10k. I imagine the final product will be cheaper.

[triplesec]

They will inevitably plummet in price over the next few time units. Look forward to fun!