Vulkan 1.0.4 Specification Published

[azari]

This is probably why one of Nvidia 's first extensions is running Vulkan inside OpenGL. Similar to how you write C code, but when you absolutely must squeeze every bit of performance you write ASM functions inside the C code.

A better way to do this however is to use opensource middleware libraries that will run on top of Vulkan, and hide some of it's intimidating low level aspects; there is already an opensource GLSL compiler that runs on top of Vulkan. That's a far better solution, whereas Nvidia's solution essentially keeps applications dependent on OpenGL for longer. OpenGL should really only matter for legacy apps; if people need user-friendly toolkits for Vulkan, those will arrive (and some have already) in due time. The driver maintenance hell that results from OpenGL in the Linux world needs to end. =\

"PC" was the term used by the source. While technically you are correct that PC is not an API, when talking about PC gaming up to now this almost exclusively means Windows and DirectX 11, with newcomers DirectX 12, Vulkan and non-Windows operating systems.

The whole point of Vulkan/DX12 is to bring the close-to-metal performance that consoles like the PS4 have, to the PC; I think what eydee was pointing out was that making a comparison of "PS4's API vs PC" seems to imply that you're stacking the deck by comparing a low level API to DX11/OpenGL. Comparing PS4's low level API to Vulkan/DX12 is far more accurate, and in that case I doubt the PS4 will have much if any of an edge at all. The era of consoles getting more bang for buck on their GPUs is coming to an end.

[chithanh]

azari
I'm sure the VR developers who made the 60% observation are already aware of DX12/Vulkan.
Also while Vulkan is a console-like low-level API, there is probably still some abstraction involved to make the games run on different hardware.

There is one very interesting Interview by Eurogamer with 4A Games about Metro Redux development on consoles. Note how besides the low-level interface they also talk about adapting to the target hardware.

So while DX12/Vulkan will reduce the PS4's edge over a similar spec PC especially when it comes to draw call bound scenarios, it will not eliminate it fully.

[bug77]

A better way to do this however is to use opensource middleware libraries that will run on top of Vulkan, and hide some of it's intimidating low level aspects; there is already an opensource GLSL compiler that runs on top of Vulkan. That's a far better solution, whereas Nvidia's solution essentially keeps applications dependent on OpenGL for longer. OpenGL should really only matter for legacy apps; if people need user-friendly toolkits for Vulkan, those will arrive (and some have already) in due time. The driver maintenance hell that results from OpenGL in the Linux world needs to end. =\

I think we have a very different understanding of where OpenGL stands and where it's going. Even so, I don't see why high level Vulkan libraries should preclude OpenGL from working with Vulkan as well. At the very least, said libraries are extremely new while OpenGL is an already known alternative.
There must be at least a little experimentation if we're to find a robust solution for the next 20+ years.

[liam]

azari
I'm sure the VR developers who made the 60% observation are already aware of DX12/Vulkan.
Also while Vulkan is a console-like low-level API, there is probably still some abstraction involved to make the games run on different hardware.

There is one very interesting Interview by Eurogamer with 4A Games about Metro Redux development on consoles. Note how besides the low-level interface they also talk about adapting to the target hardware.

So while DX12/Vulkan will reduce the PS4's edge over a similar spec PC especially when it comes to draw call bound scenarios, it will not eliminate it fully.

Abstractions don't necessarily mean slower. Rust even makes this one of their big selling points.

[Philip]

I was thinking that maybe Vulkan is a clean, easy-to-use, modern API and a good thing to learn?

And that maybe OpenGL is a complicated, cumbersome, inconsistent, weird API full of legacy warts?

I think you're correct on all of those points except one: Vulkan is not easy-to-use. It forces you to do a lot of low-level work that the OpenGL driver previously would have done for you, and there are some fundamental details that vary across GPU vendors (e.g. what memory heaps you have access to) so you need to write and test multiple code paths if you want reasonable performance, and there are lots of subtle details you can get wrong without noticing that will lead to undefined behaviour (i.e. it might work fine for you but explode on someone else's GPU).

Vulkan plus some hypothetical not-yet-existent middleware library that handles all the boring low-level details could make it easy-to-use while continuing to be clean and modern, though.

[rob11311]

I think we have a very different understanding of where OpenGL stands and where it's going. Even so, I don't see why high level Vulkan libraries should preclude OpenGL from working with Vulkan as well. At the very least, said libraries are extremely new while OpenGL is an already known alternative.
There must be at least a little experimentation if we're to find a robust solution for the next 20+ years.

One idea discussed by developers was (re-)implementing OpenGL in terms of Vulkan. A key to understand is that OpenGL has ideas of state tracking, which inevitibly in multi-threaded leads to contention for locks, which is really the reason for the lower level close-to-metal APIs, which are a better fitted for todays many-core hardware scenarios.

There probably will arise helper libraries, which aid applications or engine with the differences in memory managment, they're more flexible than adding an abstraction layer; which probably won't stand the test of time (see the middle layer mistake anti-pattern for past experience on this dealing with hardware which evolves and experiments).