4 ms·

This adds more to the evidence that Vulkan / DX12 seems like a failed API design, when too many graphics engineers are reinventing the wheel by building their r

This adds more to the evidence that Vulkan / DX12 seems like a failed API design, when too many graphics engineers are reinventing the wheel by building their render-graph API on top of these (propietary triple-A game engines, Unreal Engine, and now Godot...) Instead of real-time graphics APIs providing all these low-level manual synchronization primitives and cumbersome PSOs, maybe they should just provide an official Render Graph API instead? Provide all of the operations and its dependencies in an acyclic graph up-front, and the driver handles synchronization automatically in the most performant manner tailored to the hardware. I guess there needed some trial-and-error in the gamedev world for about a decade to really nail down a nice to use but also performant graphics API design. Vulkan being originated from the Mantle API from AMD didn't help - since it was a low-level console API mainly accustomed to AMD's GPUs and really didn't seem like it would fit for a more "general-purpose" API spanning a huge range of hardware and can stand the test of time. And with Microsoft's DX12 hastely copying from AMD's initial design it also has all the same issues (The irony is that DX11 is still the best graphics API you can use in gamedev in Windows in terms of ergonomics and even performance - seeing many trying to dauntingly build a DX12 backend and end up performing worse than DX11...) Nowadays I'm obversing that the industry has known these issues for a while and are experimenting with alternative API designs... there are some experiental render-graph extensions available in both DX12 / Vulkan (albeit in a limited fashion): - DX12's Work Graph API as preview (https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre...) - Vulkan's VK_AMDX_shader_enqueue extension (https://gpuopen.com/gpu-work-graphs-in-vulkan/ https://gpuopen.com/gpu-work-graphs-in-vulkan/)

mmis1000 3y ago
I think Vulkan / DX12 is explicitly designed to make making another abstraction on it possible? It's possible to make a full app on it without any assistant, but it's not the easiest way to use it. For example, you may make a opengl emulation layer on directX, but not the other way around. And dx12/vulkan is designed to be the underlying one (While hide some hardware specified gotcha).
- cyber_kinetist 3y ago
  The problem is... even it being low-level it isn't really a good abstraction. It mainly maps well with how AMD's hardware works but not NVIDIA's - NVIDIA has some inherent dynamic state baked into their hardware that makes the whole pipeline object thing a bit inefficient in theirs. But even ignoring this, it's a bit disheartening seeing all the graphics engineers working on game engines building similar things on top of it in suboptimal ways (ex. the pipeline cache), when it could have been just done at the driver level from the start! The reality is that most graphics application developers really do not care too much about the intricacies of low-level device management - and the ones who actually care are also building abstractions around it since they too don't really want to deal with this. Vulkan / DX12 basically feels like the driver developers have just given up and dumped the whole responsibility of managing a GPU onto the application developers. It's a bit like how even the best performance-oriented engineers rarely go down to directly writing assembly to optimize their C/C++ code - sure you can do that, but excluding the rare hot spots it's mostly a waste of time. It is incredibly useful to get a debugger/profiler and observe how your code is compiled down to, but actually writing it is cumbersome and requires too much of a discipline with too many footguns.
gmueckl 3y ago
Calling Vulkan a failed design is selling it short. There are parts like image layout tracking that should never have been exposed; tracking that at the application level does not offer any additional gains. Exposing explicit synchronization, on the other hand, is in principle the right idea. The driver gets information through those APIs that it cannot derive any other way. I believe it enables certain practical resource access patterns that would be near impossible without that. However, there may be a better way than the current pipeline barrier API to describe data and execution dependencies. Other parts of Vulkan are clear wins. Pipelines with their explicit state look more cumbersome than the OpenGL state machine when starting out on a toy renderer, but they are absolutely invaluable in anything slightly more complex. All OpenGL based renderers that I've worked with ended up building a state management abstraction on top of OpenGL to work around the debugging nightmare of forgotten state variable updates. Pipeline add this state management at the driver level.
- cyber_kinetist 3y ago
  Pipelines (or in general terms PSOs) are the most problematic aspect of Vulkan / DX12 - much more than synchronization! Large parts of the gamedev industry seems to recognize all the performance issues with pipelines and therefore companies are experimenting with newer models like the VK_EXT_shader_object extension ("Vulkan without Pipelines": https://www.khronos.org/blog/you-can-use-vulkan-without-pipelines-today https://www.khronos.org/blog/you-can-use-vulkan-without-pipe...). I've written a detailed comment about this before here (https://news.ycombinator.com/item?id=37843946#37845431 https://news.ycombinator.com/item?id=37843946#37845431) but for a much more comprehensive explanation by an engineer from Nintendo read the initial proposal for the VK_EXT_shader_object extension: https://github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_EXT_shader_object.adoc https://github.com/KhronosGroup/Vulkan-Docs/blob/main/propos...). And the slightly less-official behind-the-scenes tweet thread about the background for VK_EXT_shader_object: https://twitter.com/gfxstrand/status/1641914602756644867 https://twitter.com/gfxstrand/status/1641914602756644867 There's also Casey Muratori's mail to the Vulkan advisory on 2015 that basically predicts this whole clusterfuck would happen: https://github.com/cmuratori/misc/blob/main/vulkan_dynamic_state.md https://github.com/cmuratori/misc/blob/main/vulkan_dynamic_s...

mmis1000 3y ago

I think Vulkan / DX12 is explicitly designed to make making another abstraction on it possible? It's possible to make a full app on it without any assistant, but it's not the easiest way to use it. For example, you may make a opengl emulation layer on directX, but not the other way around. And dx12/vulkan is designed to be the underlying one (While hide some hardware specified gotcha).

cyber_kinetist 3y ago
The problem is... even it being low-level it isn't really a good abstraction. It mainly maps well with how AMD's hardware works but not NVIDIA's - NVIDIA has some inherent dynamic state baked into their hardware that makes the whole pipeline object thing a bit inefficient in theirs. But even ignoring this, it's a bit disheartening seeing all the graphics engineers working on game engines building similar things on top of it in suboptimal ways (ex. the pipeline cache), when it could have been just done at the driver level from the start! The reality is that most graphics application developers really do not care too much about the intricacies of low-level device management - and the ones who actually care are also building abstractions around it since they too don't really want to deal with this. Vulkan / DX12 basically feels like the driver developers have just given up and dumped the whole responsibility of managing a GPU onto the application developers. It's a bit like how even the best performance-oriented engineers rarely go down to directly writing assembly to optimize their C/C++ code - sure you can do that, but excluding the rare hot spots it's mostly a waste of time. It is incredibly useful to get a debugger/profiler and observe how your code is compiled down to, but actually writing it is cumbersome and requires too much of a discipline with too many footguns.

gmueckl 3y ago

Calling Vulkan a failed design is selling it short. There are parts like image layout tracking that should never have been exposed; tracking that at the application level does not offer any additional gains. Exposing explicit synchronization, on the other hand, is in principle the right idea. The driver gets information through those APIs that it cannot derive any other way. I believe it enables certain practical resource access patterns that would be near impossible without that. However, there may be a better way than the current pipeline barrier API to describe data and execution dependencies. Other parts of Vulkan are clear wins. Pipelines with their explicit state look more cumbersome than the OpenGL state machine when starting out on a toy renderer, but they are absolutely invaluable in anything slightly more complex. All OpenGL based renderers that I've worked with ended up building a state management abstraction on top of OpenGL to work around the debugging nightmare of forgotten state variable updates. Pipeline add this state management at the driver level.

cyber_kinetist 3y ago
Pipelines (or in general terms PSOs) are the most problematic aspect of Vulkan / DX12 - much more than synchronization! Large parts of the gamedev industry seems to recognize all the performance issues with pipelines and therefore companies are experimenting with newer models like the VK_EXT_shader_object extension ("Vulkan without Pipelines": https://www.khronos.org/blog/you-can-use-vulkan-without-pipelines-today https://www.khronos.org/blog/you-can-use-vulkan-without-pipe...). I've written a detailed comment about this before here (https://news.ycombinator.com/item?id=37843946#37845431 https://news.ycombinator.com/item?id=37843946#37845431) but for a much more comprehensive explanation by an engineer from Nintendo read the initial proposal for the VK_EXT_shader_object extension: https://github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_EXT_shader_object.adoc https://github.com/KhronosGroup/Vulkan-Docs/blob/main/propos...). And the slightly less-official behind-the-scenes tweet thread about the background for VK_EXT_shader_object: https://twitter.com/gfxstrand/status/1641914602756644867 https://twitter.com/gfxstrand/status/1641914602756644867 There's also Casey Muratori's mail to the Vulkan advisory on 2015 that basically predicts this whole clusterfuck would happen: https://github.com/cmuratori/misc/blob/main/vulkan_dynamic_state.md https://github.com/cmuratori/misc/blob/main/vulkan_dynamic_s...