"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).
Better for whom? The nvidia driver doesn't have proper wayland support, can't work with gallium nine, can't be included in the kernel, and has issues with v-sync.
When crooked interests hinder adoption, you should blame the crooked interests, not the technology.
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.
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.
I don't think the lock-in in the case of graphics APIs is too bad, because even for large codebases implementing a new graphics API support is often done by one or two persons.
Metal is useless outside of Apple, so it's DOA adoption wise. Developers will be of course forced to use it when targeting Apple. Adoption however means wide coverage of multiple platforms.
Again, try working on that abstraction layer, and then you'll see what it takes. Claims that it's trivial or it's normal and should be that way have no substance. It's like saying that Web developers enjoy browsers not following standards and the need to address all those quirks is trivial. No normal developer wants that.
MoltenVK[0] is a way to use the Vulkan API and shaders on Metal.
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.
> So far I have only seen Vulkan on GNU/Linux and Android 7.0+ deployments.
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.
> Vulkan is widely available on Windows, not sure how you missed that.
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]
No, you are the one still not getting how the game industry works.
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.
No, you don't get it, since adding anything to the list increases costs and slows down development. But I guess since you aren't working on those engines, you just assume magically adding a bullet point is all it takes.
SPIR-V is the intermediate language Vulkan uses for shaders, it's also the intermediate language of OpenCL - so if you implement SPIR-V for Vulkan you also get that for OpenCL - so now even if a company doesn't care about optimizing OpenCL it gets stuff from Vulkan for free
AMD management is dysfunctional (think late Commodore). They are perfectly ready to throw away $300m on a shot in the dark (seamicro) but are unwilling to hire actual developers to support their current hardware (gpu drivers still single threaded).
I won't argue with you over some of the things AMD has decided to prioritize, but for what it's worth, they are at least working on supporting CUDA compilation for their GPUs.
With multi-res and now lens-masked shading, it is no contest. Few games have started using P either technique yet, but it is an enormous performance increase.
It's silly for AMD to say that nVidia doesn't care about VR. By the same token AMD obviously cares about HPC, even when they say they're "all in" on VR in some press release.
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.
HPC? NVidia is completely destroying AMD on the deep learning front. The most popular deep learning frameworks use CUDA and do not have stable OpenCL support out of the box.
The most popular deep learning frameworks use CUDA and do not have stable OpenCL support out of the box.
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.
Most libraries have fallbacks for cuDNN-less operation. Torch, for example, requires you to import a CUDNN library if you want to use it. Caffe requires you to uncomment a line in a makefile if you want to use it.
I like nextplatform and nvidia did just have a great quarter. Tensorflow runs best when accelerated by nvidia GPUs.
However, the article vastly oversells nvidia in the HPC space. Intel's MIC platform is targeted at competing with GPUs, and cuda is a closed standard. Nvidia is by no means dominant in HPC, and has parts in only two machines in the top-10, and none that I'm aware of under contruction.
Finaly, Exascale architecture is likely to be radically different than present tech. It could absolutely shake up the environment significantly.
I believe the DOD already has plans to bring online two new computers in the near future that will retake the crown. At least one of them with Nvidia with a big emphasis on P100 and nvlink.
Summit and Sierra are two planned DOE machines with hardware developed in collaboration with IBM and Nvidia. They're slated to feature Volta GPU, a generation past P100's Pascal.
- "Fiscal 2017" may not be the calendar year, e.g. it could comprise April-2016 to March-2017. (I don't know the specifics here, but accounting is weird that way.)
- There's booking, and "book-to-bill ratio" in the semiconductor industry. I.e. the pre-orders are recorded quite a bit in advance, but actual shipments (and payments) may vary.
For me not obvious why they predict small failure in sales in Q1 2017, if 1080ti will be released in Q1 2017 - and by current information it will be awesome card for gaming.
Training - I have a feeling it's going to be NVidia for a while. AMD just doesn't show interest in joining the party, and NVidia has been optimising CuDNN for a while now, it will take a bit of time to play catch up. I really don't understand what AMD have been doing the past 2 years here.
Inference - NVidia will have a much harder time enforcing a monopoly here, because they are not, and cannot be the dominant player on all the hardware where neural networks will run after training. ARM, Qualcomm and others in mobile space will be pushing it hard, as will vendors running neural nets on FPGA/ASIC designs that are now emerging.
Will be interesting to see what effect architectures using low precision or binary weights (for both training and inference) will have too on the hardware landscape.
SPIR-V - AFAIK Codeplay (https://www.codeplay.com) are working on SPIR-V support for tensorflow, that should in theory help to use TF on various hardware that supports Vulkan/SPIR-V. But I guess each vendor will still need to tune things like convolution kernels for their specific hardware to squeeze the best perf out
I think you might be overestimating the worldwide impact of that, though. AMDs are used for "mining crypto" - they're the best for that purpose - and no, that also is nothing to write home about. Despite being very present in my personal circles.
The amount of people doing either is minuscule in comparison to gaming. Those buying big for datacentres are definitely accounted for by nVidia. They don't buy GTX cards.
76 comments
[ 2.8 ms ] story [ 283 ms ] threadAnd 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-...
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.
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)
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.
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.
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.
[0] https://moltengl.com/moltenvk/
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.
[0] https://moltengl.com/moltenvk/
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.
Bad Linux support, Bad Debugging, unreliable processing times between vendors (> 40% between same gen. GPUs), missing or buggy functions.
http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia...
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.
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.
However, the article vastly oversells nvidia in the HPC space. Intel's MIC platform is targeted at competing with GPUs, and cuda is a closed standard. Nvidia is by no means dominant in HPC, and has parts in only two machines in the top-10, and none that I'm aware of under contruction.
Finaly, Exascale architecture is likely to be radically different than present tech. It could absolutely shake up the environment significantly.
More details here: https://www.olcf.ornl.gov/summit/
I have found memories of the language.
- "Fiscal 2017" may not be the calendar year, e.g. it could comprise April-2016 to March-2017. (I don't know the specifics here, but accounting is weird that way.)
- There's booking, and "book-to-bill ratio" in the semiconductor industry. I.e. the pre-orders are recorded quite a bit in advance, but actual shipments (and payments) may vary.
Inference - NVidia will have a much harder time enforcing a monopoly here, because they are not, and cannot be the dominant player on all the hardware where neural networks will run after training. ARM, Qualcomm and others in mobile space will be pushing it hard, as will vendors running neural nets on FPGA/ASIC designs that are now emerging.
Will be interesting to see what effect architectures using low precision or binary weights (for both training and inference) will have too on the hardware landscape.
SPIR-V - AFAIK Codeplay (https://www.codeplay.com) are working on SPIR-V support for tensorflow, that should in theory help to use TF on various hardware that supports Vulkan/SPIR-V. But I guess each vendor will still need to tune things like convolution kernels for their specific hardware to squeeze the best perf out
Everyone I know who are doing deep learning have been buying Titan X's or GTX 1080's - their "gaming" cards. Not the datacentre or pro viz cards.
The amount of people doing either is minuscule in comparison to gaming. Those buying big for datacentres are definitely accounted for by nVidia. They don't buy GTX cards.