Pascal GPUs on All Fronts Push Nvidia to New Highs
nextplatform.com
nextplatform.com
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-...
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.
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.
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/
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.
- "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.
I have found memories of the language.