Driver support going away after a few years, random issues, etc
Every single nVidia card I used under linux just worked TM (ofc I'm not "pure" because I really couldn't care less about open vs closed drivers)
It is strictly worse. NVidia not only has no interest in having a Mesa driver, but would prefer if they didn't have to compete with Mesa at all.
They're both big companies that put lots of effort & money into many things simultaneously.
Not to mention that today is the day that AMD announced public availability of CUDA for their platform.
http://www.anandtech.com/show/10831/amd-sc16-rocm-13-release...
It's worse than that. The popular frameworks use cuDNN, which is a hand (assembler) optimized library for common operations. AMD does not have any equivalent. Even if you have OpenCL support you'll get nowhere the performance.
http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia...
Now that Vulkan is out, that's far less important than it used to be.
NVidia doesn't care about OpenCL.
Google doesn't care, and pushes Renderscript instead.
Apple doesn't care, it created OpenCL, but since Khronos doesn't dance their music, they rather push Metal Compute Shaders.
Microsoft has C++AMP and DX Compute.
Additionally CUDA was designed to be targeted by multiple languages, while OpenCL had to wait for OpenCL 2.0 for it to happen.
Also the graphical debuggers for OpenCL could get some love.
I know which GPU makers I will keep giving my money to.
Anyway, Vulkan provides lower level access to the compute functionality. And MS and Apple can get lost with their selfish NIH approach. The rest are supporting Vulkan, including all GPU makers.
So far I have only seen Vulkan on GNU/Linux and Android 7.0+ deployments.
And I am willing to bet it won't change, specially since most of us only care about middleware engines nowadays.
Guess which API was being discussed at Unite 2016 LA? Hint: it wasn't Vulkan.
Vulkan is widely available on Windows, not sure how you missed that.
You can also use the Vulkan API today on iOS and OS X via a third-party library that translates between the Vulkan APIs and Metal, called MoltenVK.[0]
MoltenVK is not complete, but it covers the majority of the functionality (including SPIR-V shader ingestion) and I don't see any technical roadblocks to most of the remaining work.
I have not missed, just haven't seen too many caring about it on the Windows game development forums.
> You can also use the Vulkan API today on iOS and OS X via a third-party library that translates between the Vulkan APIs and Metal, called MoltenVK.[0]
Zero advantages versus middleware engines.
I guess you visit wrong forums. All major engine developers are busy with it.
Those game engines support the graphics APIs from, PS3, PS4, PSP, PSP Vita, Wii, 3DS, OpenGL, DX9, DX10, DX11, DX12, WebGL, Metal, Vulkan.
Adding support for Vulkan is just yet another bullet point on that list, just like they are busy adding Metal support, as it was discussed at Unite LA.
The people that actually use those engines to make games, don't care what APIs are abstracted by those engines, as long as, their game is fast, takes full advantage of the GPU and targets the game system they want to sell to.
OpenGL ES?
(also with compute shaders in the latest version...)
You keep repeating it, but it's nonsense, because it always matters how hard is for the engine to target multiple platforms.
Yet that is what professional game developers care about, not API wars.
Maybe you should attend a GDC event.
I guess the iPhone market won't get Vulkan hence the interest?
MoltenVK doesn't currently support Vulkan compute shaders, I don't see why it couldn't in the future—compute shaders are SPIR-V and actually easier to support than graphics shaders IMO. I suspect they just haven't gotten to it yet.
Everyone.
> And I am willing to bet it won't change
MS and Apple will sleep until they'll realize, their NIH is threatened by competition. They don't play nice otherwise. But you expressed multiple times that you like lock-in, so I doubt you'll appreciate it.
Bad Linux support, Bad Debugging, unreliable processing times between vendors (> 40% between same gen. GPUs), missing or buggy functions.
They did get their chips in both the major consoles, so maybe that focus on squeezing costs out if the mid-range is working out.
VR performance on AMD card is abysmal, GTX 1060 beats a fury x once you count time warped and reprojected frames.
And AMD just doesn't care - literally:
"For the most part, because—in the case of Nvidia—they don't appear to care that much about VR. And in the case of the dollars spent on R&D, they seem to be very happy doing stuff in the car industry, and long may that continue—good luck to them. We're spending our dollars in the areas we're focused on."[1]
Everytime someone complains about how little OpenCL is used, I just think of that quote. I'm happy to use products from a company that cares about what I do.
(And yes, good OpenCL implementations would be great too. But the world won't wait for AMD on this).
[1] http://arstechnica.co.uk/gadgets/2016/04/amd-focusing-on-vr-...