Hacker News Reader

Comment by pjmlp | 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.

View on HN

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

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

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.

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.

Reply on news.ycombinator.com