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)
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/
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.
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.
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.
> 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.
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.
But it's not "pure C". C is just the glue. You can use the C++ API if that's what you want, and you have a completely object-oriented API.
Can Linux never have an "OO interface" because all syscalls trap into a kernel written purely in C? Of course not, that would be silly. The same is true here. If you program against an object-oriented C++ interface, then you have a fully object-oriented API.
I find interesting that a Rust designer thinks otherwise.
You can easily call into something with a C ABI (er, OS ABI designed around C, or whatever is the correct technical name) from any language. Try that with C++ :D
C++ provides better tools to write safer code than C ever will.
I would rather be using Ada, Rust, System C#, D, <whatever safe systems programming language>, but until OS vendors start providing something else, C++17 will have to do.
Since 1994 I only write C code when forced to do so.
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).