Out of the modern non-console 3D APIs (Metal, D3D12, Vulkan), Vulkan is arguably the worst because it simply continued the Khronos tradition of letting GPU vendors contribute random extensions which then may or may not be promoted to the core API, lacking any sort of design vision or focus beyond the Mantle starting point.
Competition for 3D APIs is more important than ever (e.g. Vulkan has already started 'borrowing' a couple of ideas from other APIs - for instance VK_KHR_dynamic_rendering (e.g. the 'render-pass-object-removal') looks a lot like Metal's transient render pass system, just adapter to a non-OOP C API).
It sounds like maybe Khronos should handle 3D APIs like they do with slang[1] and just host someone else's API such as Diligent Engine or BGFX and then let them govern it's development.
Just like with Mantle, Slang came to Khronos, because after they stated they would not be doing any further GLSL development, and it was up to the community to keep using HLSL or do something else themselves, a year later NVidia decided to contribute the Slang project.
But that's not even the point. Everyone could collaborate on the common API and make it better. Where were Apple and MS? Chasing their NIHs instead of doing it, so you argument is missing the point. It's not about how good it is (and it is good enough, though improving it is always welcome), it's about it being the only collaborative and shared effort. Everything else is simply irrelevant in result even if it could be better in some ways.
Seeing what a clusterf#ck OpenGL 3 and 4 were (and Vulkan ended up being), and how Direct3D 11 is probably the most usable 3D API right now, both Apple and Microsoft were absolutely right to chase their own APIs. If not for competition from Metal and D3D12, Vulkan would still be forcing render passes and static pipelines.
Vulkan only exists because DICE and AMD were nice enough to contribute their Mantle work to Khronos, otherwise they would still be wondering what OpenGL vNext should look like.
> otherwise they would still be wondering what OpenGL vNext should look like.
And the world would have been a better place. All we needed in OpenGL 5 was a thread-safe API with encapsulated state and more work on AZDO and DSA. Now, everyone has to be a driver developer. And new extensions are released one-by-one to make Vulkan just a little more like what OpenGL 5 should have been in the first place. Maybe in 10 more years we'll get there.
I used to be a big OpenGL advocate all the way up to Long Peaks, eventually I came to realise it is another committee driven API, and writing a couple of plugin backends was never that much of a deal.
Just see the shading mess as well, with GLSL lagging behind, most devs using HLSL due to its market share, and now Slang, which again was contributed by NVidia.
Also the day LunarG loses out their Vulkan sponsorship, the SDK is gone.
I can't imagine the world without Vulkan because while it is a lot lower level and more difficult to work with, it makes things like DXVK not only possible but quite performant. Gaming on Linux has been accelerated super strongly by projects like that.
Hard disagree. OpenGL state management was unfixable if it had to keep compatibility with OpenGL 2. That's why OpenGL 3/4 ended up being such huge messes.
The main problem with Vulkan is that Apple decided to go with its own Metal API, completely fracturing the graphics space.
IMO without SPIR-V, OpenGL 5 would still be at a disadvantage in many scenarios. It's possible we would have gotten widespread support for it even without Vulkan, though.
Dx12 was release 2 years before Vulkan…
And there are plenty of advantages to having control over an API instead of putting it in some slow external organization without focus
I think Vulkan adoption was hurt by how much more complicated it was to use efficiently early on.
Considering that DX12 made it out earlier, and it took some time for Vulkan to finally relax some of its rules enough to be relatively easy to use efficiently, I think it just lost momentum.
Out of the modern non-console 3D APIs (Metal, D3D12, Vulkan), Vulkan is arguably the worst because it simply continued the Khronos tradition of letting GPU vendors contribute random extensions which then may or may not be promoted to the core API, lacking any sort of design vision or focus beyond the Mantle starting point.
Competition for 3D APIs is more important than ever (e.g. Vulkan has already started 'borrowing' a couple of ideas from other APIs - for instance VK_KHR_dynamic_rendering (e.g. the 'render-pass-object-removal') looks a lot like Metal's transient render pass system, just adapter to a non-OOP C API).
It sounds like maybe Khronos should handle 3D APIs like they do with slang[1] and just host someone else's API such as Diligent Engine or BGFX and then let them govern it's development.
[1]: https://shader-slang.org/
Just like with Mantle, Slang came to Khronos, because after they stated they would not be doing any further GLSL development, and it was up to the community to keep using HLSL or do something else themselves, a year later NVidia decided to contribute the Slang project.
You can read about DX12 being worse here: https://themaister.net/blog/2021/11/
But that's not even the point. Everyone could collaborate on the common API and make it better. Where were Apple and MS? Chasing their NIHs instead of doing it, so you argument is missing the point. It's not about how good it is (and it is good enough, though improving it is always welcome), it's about it being the only collaborative and shared effort. Everything else is simply irrelevant in result even if it could be better in some ways.
Seeing what a clusterf#ck OpenGL 3 and 4 were (and Vulkan ended up being), and how Direct3D 11 is probably the most usable 3D API right now, both Apple and Microsoft were absolutely right to chase their own APIs. If not for competition from Metal and D3D12, Vulkan would still be forcing render passes and static pipelines.
3 replies →
They were having fun with Sony and Nintendo.
Vulkan only exists because DICE and AMD were nice enough to contribute their Mantle work to Khronos, otherwise they would still be wondering what OpenGL vNext should look like.
> otherwise they would still be wondering what OpenGL vNext should look like.
And the world would have been a better place. All we needed in OpenGL 5 was a thread-safe API with encapsulated state and more work on AZDO and DSA. Now, everyone has to be a driver developer. And new extensions are released one-by-one to make Vulkan just a little more like what OpenGL 5 should have been in the first place. Maybe in 10 more years we'll get there.
I used to be a big OpenGL advocate all the way up to Long Peaks, eventually I came to realise it is another committee driven API, and writing a couple of plugin backends was never that much of a deal.
Just see the shading mess as well, with GLSL lagging behind, most devs using HLSL due to its market share, and now Slang, which again was contributed by NVidia.
Also the day LunarG loses out their Vulkan sponsorship, the SDK is gone.
2 replies →
I can't imagine the world without Vulkan because while it is a lot lower level and more difficult to work with, it makes things like DXVK not only possible but quite performant. Gaming on Linux has been accelerated super strongly by projects like that.
8 replies →
Hard disagree. OpenGL state management was unfixable if it had to keep compatibility with OpenGL 2. That's why OpenGL 3/4 ended up being such huge messes.
The main problem with Vulkan is that Apple decided to go with its own Metal API, completely fracturing the graphics space.
3 replies →
IMO without SPIR-V, OpenGL 5 would still be at a disadvantage in many scenarios. It's possible we would have gotten widespread support for it even without Vulkan, though.
1 reply →
Dx12 was release 2 years before Vulkan… And there are plenty of advantages to having control over an API instead of putting it in some slow external organization without focus
I think Vulkan adoption was hurt by how much more complicated it was to use efficiently early on.
Considering that DX12 made it out earlier, and it took some time for Vulkan to finally relax some of its rules enough to be relatively easy to use efficiently, I think it just lost momentum.