3 ms·

Vulkan tries to avoid some performance pitfalls of OpenGL by requiring the application to be more explicit about what it's doing, and have the application take

Vulkan tries to avoid some performance pitfalls of OpenGL by requiring the application to be more explicit about what it's doing, and have the application take over responsibility for some aspects of resource management and synchronisation. This means that, if the application developers know what they're doing, they can use Vulkan to make better choices than the OpenGL driver would have made for them. Also, Vulkan skips all input validation at runtime, which reduces CPU overhead. It's not actually “closer” to the hardware than OpenGL was though, it's just an attempt to define a more predictable abstraction. The underlying architecture of two Vulkan GPUs can be wildly different.

cyber_kinetist 4y ago
Absolutely, Vulkan is still nevertheless an abstraction that currently happens to fit well on today’s commodity GPUs. Maybe 20 years later we might have some changes in the hardware design space such that Vulkan might not be fit for efficient real-time rendering anymore, who knows? (I think recent advances in things like CUDA, mesh shaders, and RTX already show this and point towards a departure from “conventional” graphics pipelines…)
- yarg 4y ago
  (If I remember rightly) the culling capabilities of mesh shaders are absolutely staggering - and the performance gains are in no way vendor restricted.
phkahler 4y ago
>> The underlying architecture of two Vulkan GPUs can be wildly different. Cool. When I read that bit about exposing hardware I was afraid that meant having to query for various capabilities and adapt ones code to it, which is not an abstraction at all. I'm guessing you can ask which Vulkan capabilities are present, but not actual hardware details?
- d_tr 4y ago
  There is a large list of things you can query, like for example the number of available queues and then the types of commands supported by each queue. I think this can be considered as a hardware detail. It's like querying the execution ports of your CPU.

cyber_kinetist 4y ago

Absolutely, Vulkan is still nevertheless an abstraction that currently happens to fit well on today’s commodity GPUs. Maybe 20 years later we might have some changes in the hardware design space such that Vulkan might not be fit for efficient real-time rendering anymore, who knows? (I think recent advances in things like CUDA, mesh shaders, and RTX already show this and point towards a departure from “conventional” graphics pipelines…)

yarg 4y ago
(If I remember rightly) the culling capabilities of mesh shaders are absolutely staggering - and the performance gains are in no way vendor restricted.

phkahler 4y ago

>> The underlying architecture of two Vulkan GPUs can be wildly different. Cool. When I read that bit about exposing hardware I was afraid that meant having to query for various capabilities and adapt ones code to it, which is not an abstraction at all. I'm guessing you can ask which Vulkan capabilities are present, but not actual hardware details?

d_tr 4y ago
There is a large list of things you can query, like for example the number of available queues and then the types of commands supported by each queue. I think this can be considered as a hardware detail. It's like querying the execution ports of your CPU.