Hacker News Reader

Comment by nl | Hacker News Reader

Yep.

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-...

View on HN

AMD cares to contribute to Mesa. Nvidia? Not really.

NVidia have their own high-quality OpenGL implementation. Isn't that better?

No.

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.

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.

Indeed. While radeonsi continues to march forward, Nvidia doesn't rush to address the above. My next card is going to be Vega.

Yet AMD cards under linux are complete misery

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'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.

http://www.anandtech.com/show/10831/amd-sc16-rocm-13-release...

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.

And today AMD announced support for CUDA and hinted that they were deprecating OpenCL (by releasing OpenCL 1.2+ rather than concentrating on 2.0).

What? AMD's drivers have had OpenCL 2.0 support for a long time. At least on Windows.

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.

As already said, you'll get nowhere the performance.

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.

http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia...

And today AMD announced public availability of CUDA: http://www.anandtech.com/show/10831/amd-sc16-rocm-13-release...

> good OpenCL implementations would be great too

Now that Vulkan is out, that's far less important than it used to be.

i wasn't even aware vulkan obviated openCL...

I don't know a ton about the subject, but there's some coverage of it in this overview: https://www.khronos.org/assets/uploads/developers/library/ov...

They overlap to some degree. Vulkan allows access to compute queues of the GPU (in addition to graphics ones).

OpenGL already does that via compute shaders and it hasn't helped.

Hasn't helped what exactly? OpenGL can't provide proper parallelized access to all the queues, so having compute shaders there isn't that useful.

To gain adoption.

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.

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.

What rest?

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.

> What rest?

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.

You keep forgetting Sony and Nintendo.

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.

Guess which API was being discussed at Unite 2016 LA?

OpenGL ES?

(also with compute shaders in the latest version...)

Metal support.

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.

Middleware engines have won the hearts of game developers, it doesn't matter what runs underneath, only for those that do API religion.

> it doesn't matter what runs underneath

You keep repeating it, but it's nonsense, because it always matters how hard is for the engine to target multiple platforms.

It is nonsense to you, because all your arguments fail flat when there is an abstraction layer that hides away what actual APIs are being used.

Yet that is what professional game developers care about, not API wars.

Maybe you should attend a GDC event.

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.

Huh I admit this is really surprising.

I guess the iPhone market won't get Vulkan hence the interest?

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.

[0] https://moltengl.com/moltenvk/

> 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.

[0] https://moltengl.com/moltenvk/

> 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]

Zero advantages versus middleware engines.

> I have not missed, just haven't seen too many caring about it on the Windows game development forums.

I guess you visit wrong forums. All major engine developers are busy with it.

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

Vulkan Compute shader have exactly the same problems like OpenCL or OpenGL Compute shader.

Which are?

Sorry for the delayed answer but for verification I had to update my SDK to perform the tests:

Bad Linux support, Bad Debugging, unreliable processing times between vendors (> 40% between same gen. GPUs), missing or buggy functions.

It seems like their focus is more on the mainstream (~$200) cards than the high-end.

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.

If AMD cared about VR it would have implemented viewport multi casting which NVIDIA has supported since Kepler.

VR performance on AMD card is abysmal, GTX 1060 beats a fury x once you count time warped and reprojected frames.

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.

Check the performance benchmarks :)

They invest into efficiency. So they will be second in VR. But provide more battery and therefore more game time.

And you can use their VR device as a warm winter hat.

Reply on news.ycombinator.com