Hacker News Reader

It is like Khronos keeps missing the point why developers jump into more productive eco-systems.

Lets see how they manage Vulkan, which keeps getting extensions that NVidia and AMD first develop in DirectX anyway, like Raytracing and mesh shaders.

Google and Samsung had to adapt Microsoft's HLSL compiler to target SPIR-V, because plenty of game developers weren't willing to write GLSL, or to port their shaders.

For those that don't know shading languages HLSL is closer to C++ in language features, also similar to what PS4 uses, while GLSL is pretty much still stuck in being a C derived shading language.

Well, now that SPIRV is upon us, we can write a custom shading language which targets SPIRV

You can, the point is who will care to use it, and which graphical tools across the industry will care that it exists.

Hence why Google and Samsung spent about one year doing it for HLSL, and it still isn't 100% compliant with DXIC.

> It is like Khronos keeps missing the point why developers jump into more productive eco-systems.

Implementation and standardization should go hand-in-hand, to make sure that you don't standardize something that's unimplementable.

If you can't find companies to implement the standard while it's being developed, then maybe nobody cares?

Indeed, just take a look at the slide about which OpenCL version each company is supporting.

>It is like Khronos keeps missing the point why developers jump into more productive eco-systems.

They have a history of doing it for the past 20 years. So when the article said "Taking some hard earned (and hard learned) lessons to heart,". I laughed.

I am not even sure they learned anything. And it is the same reason I dont understand why everyone is chanting Vulkan. It is the same /similar story with OpenGL vs 3DFx Glide.

I believe it's because the alternatives are controlled by Microsoft, isnt it?

Microsoft, Apple, Nintendo and Sony.

Contrary to urban myths Khronos APIs have little uptake on consoles, if they are supported at all.

Isn't Vulkan supported on Series X or PS5? That wouldn't surprise me, given every vendor wants to rule with their API.

Series X is DirectX 12 Ultimate, and the PS5 will most likely have another generation of LibGNM/LibGNMX.

Even on Switch there is the option of going with NVN or middleware like Unity and Unreal.

According to Unity official numbers, they have about 50% of share across Switch titles.

Thanks a lot for the answer!

So no Vulkan at all for Series X? Not even planned? That is sad but expected :(

Vulkan is a breath of fresh air compared to OpenGL. The documentation is great, it runs everywhere, and if it passes validation I get consistent results on whatever hardware I want to run it on.

I'm not sure why I would want to target 4+ proprietary API's instead of one modern, open API which is well-designed and performs great.

Just wait a couple of releases more until the extension registry starts matching the OpenGL one, and one needs to write multiple code paths depending on the targeted GPUs.

Is that not equally true of DX12? How can I execute mesh shaders on hardware which doesn't support them?

This is not a sin of Vulkan, it's just the reality of a fragmented GPU landscape.

At least Vulkan has a sensible, consistent API around extensions, and makes it easy to verify that your hardware has the capabilities you need in order to use a given feature.

It won't start at all because it requires DirectX 12 Ultimate drivers.

DirectX 12 Ultimate is a different thing than DirectX 12. Game developers aren't just going to be able to target Ultimate if they want to capture any users with older than current generation NVIDIA or next gen AMD GPUs.

edit: if I was using Vulkan and only wanted to target DX12 Ultimate-certified hardware I would still be able to use only one code-path. This would basically mean that I am choosing to only support hardware which supports a certain set of extensions

They have enough customers on XBox ecosystem.

You’re arguing that DX12 is better than Vulkan because it has exactly the same characteristics as Vulkan.

If only Vulkan had an SDK half as good.

That wasn't your argument but go ahead and move the goal posts all you want.

No, the original argument was that DirectX, or any other proprietary API from Apple, Nintendo and Sony, don't need the extension jungle of Vulkan and OpenGL, the former with almost weekly updates.

Which than feds into learning the APIs and not having to deal with multiple execution paths.

In DirectX there is only one way of doing RayTracing, in the Khronos APIs, well it depends. Same applies to lots of other features.

You're comparing apples and oranges. Your argument is that proprietary API's are better than Vulkan because there are less code paths, but if you go that way you need a completely separate code path for each top-level API.

I think you're vastly over-stating the complexity of handling this in Vulkan. For the ray-tracing example, realistically you have one branch for non-ray-tracing, and one more where you check for whatever RT extensions you need and do ray-tracing if you have them available. This is exactly the same complexity you would have with DX12.

DX12 Ultimate is a really poor counterpoint. No serious game developer is going to be content targeting only XBoxSX and PCs build for over $1200 in the last 18 months. Realistically, even if you only target MS platforms, you're probably even going to need a DX11 renderer, and the DX12 API is already quite different on XBox and PC, so that's already 3 code-paths minimum.

> Google and Samsung had to adapt Microsoft's HLSL compiler to target SPIR-V, because plenty of game developers weren't willing to write GLSL, or to port their shaders.

What is your argument here exactly? Isn't it one of the stated benefits of Vulkan, that because of SPIR-V as a shader language, developers can choose whatever high-level language they write to implement shaders in?

If developers can target Vulkan without re-writing their shaders that seems like a sign of strength not a sign of weakness.

It is a weakness, because they had to adopt the competition's shading language, as they weren't able to improve their own.

Also in the age of middleware, Vulkan is only a checkbox away, so unless one is writing game engines, it is quite irrelevant.

For example, OctaneRender gave up on the Vulkan backend and replaced their prototype with Optix 7.

I bet no one on the VFX movie industry will care one second about their change.

It's like you didn't even read my comment

edit: just for the record, pjlmp added everything after the 1st line to his comment after I posted this response

I did, not being able to offer something better than the competition is a weakness, regardless of the opportunities that SPIR-V allows for.

GLSL is not part of Vulkan's value proposition and has no bearing on Vulkan's success. The competitive feature which Vulkan offers is it's non-proprietary nature and crosss-platform support. If it can deliver that with the same or better performance as proprietary solutions, and offering developers more choice about which language they want to implement shaders in, this is a clear win for Vulkan.

As an outsider reading this, it sounds like OpenGL vs DirectX all over again - an open API is good, but a good API is better.

Alternative take: An Open API is good, but Microsoft and Nvidia are too powerful to allow it

http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-an...

I'm not much of a graphics programmer, so take this with a grain of salt, but from talking to people who are, the impression I've gotten is that OpenGL is stuck in this weird middle state where it still has two ways of doing things, a simple and easy, but inefficient way where you specify everything from scratch each frame, and one where you use more persistent state like vertex buffer objects to minimize copying and speed things up, but the latter has a cumbersome bolted-on-top API. By comparison DirectX only supports the latter, but was from the start designed with a nicer API to deal with this persistent state, so engine programmers tend to prefer it. And rumor has it that it was the CAD companies that were preventing a modernization of the OpenGL API to properly compete with the ease-of-use of DirectX. So this wasn't just a fight of open vs proprietary, it was also a fight of design-by-committee vs single coherent architectural vision.

This isn't really accurate; the immediate-mode approach you're talking about was deprecated in OpenGL 3.0 and was never supported in OpenGL ES, and in fact, Direct3D started out with an immediate-mode API just like OpenGL before moving to retained vertex buffers.

As someone who spent quite a bit of time with OpenGL, this criticism never really scanned with me. Yes there were multiple ways to do things, but it was fairly easy to understand what the modern parts of the API were and just use that subset. If you run through any modern OpenGL tutorial it will explain this very concisely, and I never had an issue being unsure which parts of the API to use.

That said, Vulkan really does solve all of the real pain-points which existed with OpenGL. It’s very well documented and nice to use, and I really don’t understand why anyone would choose a proprietary api over it.

What about a good, open API like Vulkan?

I just want to be able to install a program or library, like Tensorflow, and have it work on my GPU whether it's from Nvidia or AMD without having to first find and install the right compiler.

How do I run a Python program that imports Tensorflow on my AMD GPU today?

That's something you need to ask to your package manager. Making sure that all dependencies of a package (e.g. drivers, compilers, etc.) are installed is the package manager's job.

If you are installing TF from source, then it becomes your job. TF docs should help you here, and TF's build-system should be able to guide you through what you need to install.

> That's something you need to ask to your package manager. Making sure that all dependencies of a package (e.g. drivers, compilers, etc.) are installed is the package manager's job.

No that's bullshit and it shows you never have done it.

Tensorflow is CUDA only and does not run over AMD GPU. Because CUDA is proprietary and has a monopoly on GPGPU for now.

It is such a big deal that AMD had to fork tensorflow and try to make their own version it in order to make it "partially" run over HIP. This naturally makes it behind upstream, buggy and partially updated [^1]

CUDA is not portable and will never be.

The sad truth is that, due to CUDA, a big majority of GPGPU programs are now vendor lock-in on Nvidia hardware. That is unacceptable, but it is like that.

[^1]: https://github.com/ROCmSoftwarePlatform/tensorflow-upstream

> It is such a big deal that AMD had to fork tensorflow and try to make their own version it in order to make it "partially" run over HIP.

That's because HIP requires changes to the program source code, but AMD has managed to upstream those patches to other projects. If they haven't done that for Tensorflow, that's kind of their problem.

Clang can compile CUDA code, and it has an AMDGpu backend. AMD could compile that CUDA code to SPIRV if they wanted. Intel and PGI do compile CUDA to x86-64 using LLVM without problems.

> How do I run a Python program that imports Tensorflow on my AMD GPU today?

https://rocm-documentation.readthedocs.io/en/latest/Deep_lea...

ROCm is only officially supported on AMD Instinct GPUs. For others, it’s a best effort thing only:

“ AMD ROCm is validated for GPU compute hardware such as AMD Radeon Instinct GPUs. Other AMD cards may work, however, they are not officially supported at this time. We appreciate your feedback and we will consider it for future versions of ROCm.”

https://github.com/RadeonOpenCompute/ROCm/issues/887#issueco...

> ROCm officially supports AMD GPUs that use following chips:

> "Vega 10" chips, such as on the AMD Radeon RX Vega 64 and Radeon Instinct MI25

https://github.com/RadeonOpenCompute/ROCm

Right. Because they happen to use the same chip.

But if you’re using the current consumer product line, it’s hit or miss.

> CUDA can now easily compile it to target NVIDA and AMD GPUs, as well as x86-64 CPUs

Are these solutions "legal"? I.e. is there a risk NVIDIA can crack down on tools like this from an IP standpoint if they want to at some point in the future?

IANAL, but:

- NVIDIA themselves ship multiple CUDA to multi-core x86-64 compilers for different programming languages CUDA C/C++/Fortran

- AMD has been shiping hip for a while, advertising it as production ready, without any lawsuits (AFAIK). hip is also being used in production.

- LLVM and clang have had open-source CUDA (and PTX) support for years, and nvidia have not enforced any kind of patents there.

That clang/LLVM support was contributed by NVidia.

I think it was contributed by Google.

The original version of the NVPTX backend was contributed by nvidia, but iiuc they abandoned it afterwards and I think all the work on it since then has been by Google.

> AMD has been shiping hip for a while, advertising it as production ready, without any lawsuits (AFAIK). hip is also being used in production.

Hip is not Cuda and even remove most mention if cuda from its API. It just mimic cuda API to try to provide compatibility.

And the result is that almost nobody use it today.

How do people do GPGPU on AMD today? Because I thought AMD has a huge cloud GPU market share for things like ML

> How do people do GPGPU on AMD today? Because I thought AMD has a huge cloud GPU market share for things like ML

ROCm and HIP [^1] or OpenCL.

OpenCL is the hated solution of GPGPU. It is low level, incomplete and definitively not with a mature ecosystem of tools like Cuda. But it is currently the only one existing if you want your program to run on something else than Nvidia GPU ( Meaning AMD, Intel, phone GPUs or FPGA accelerators).

[^1] https://github.com/ROCmSoftwarePlatform/

Android phone GPUs only do Renderscript, OpenCL is not officially supported on Android.

AMD has a tiny market share in the cloud GPU market. AWS, Google Cloud, and Azure all have compute instances with NVIDIA GPUs, and I don't think any with AMD GPUs (IIRC Azure maybe has windows instances with AMD GPUs for graphics).

According to https://www.techquila.co.in/nvidia-cloud-ai-gpu-share/, AMD is at ~1%.

Can you patent a formal language or API calls ? That's a real question.

I'm sure NVIDIA IP includes the CUDA trademark, their own compilers, SDKs and so on... but the language itself ?

It's a gray area and currently being litigated. If Oracle prevails, then NVidia absolutely would be in a position to shut down compatible implementations of CUDA, or dictate the terms under which they might or might not be able to continue to exist.

Using open standards avoids this risk, though some companies are unwilling to work with Khronos, citing (not publicly detailed) legal concerns.

[1]: https://en.wikipedia.org/wiki/Google_v._Oracle_America

With regards to HIP, here is a quote from AMD's FAQ:

> Most developers will port their code from CUDA to HIP and then maintain the HIP version. HIP code provides the same performance as native CUDA code, plus the benefits of running on AMD platforms.

E.g. AMD wants developers to develop primarily in HIP. The CUDA->HIP transpilation tools is to help developers make the switch.

You'd think Khronos would learn from their (many) past mistakes with OpenGL but apparently they seem to miraculously have found some leftover foot left to shoot. I guess hindsight is 20/20 and all that but it's pretty crazy that they seem to miss the mark so reliably over the years.

Nah, just check the Vulkan extensions registry.

Issues

1) Are there issues?

RESOLVED: Yes.

https://www.khronos.org/registry/vulkan/specs/1.2-extensions...

Honestly the whole thing makes me sick. And now effin Khronos comes up with their 15th grand new idea.

Every party in this is a PoS in once sense or another.