5 ms·

You can use descriptor heaps with existing bindless shaders if you configure the optional "root signature". However it looks like it's simpler to change your s

by exDM69 8mo ago

You can use descriptor heaps with existing bindless shaders if you configure the optional "root signature". However it looks like it's simpler to change your shaders (if you can) to use the new GLSL/SPIR-V functionality (or Slang) and don't specify the root signature at all (it's complex and verbose). Descriptor heaps really reduce the amount of setup code needed, with pipeline layouts gone you can drop like third of the code needed to get started. Similar in magnitude to dynamic rendering.

flohofwoe 8mo ago
Having quite recently written a (still experimental) Vulkan backend for sokol_gfx.h, my impression is that starting with `VK_EXT_descriptor_buffer` (soon-ish to be replaced with `VK_EXT_descriptor_heap`), the "core API" is in pretty good shape now (with the remaining problem that all the outdated and depreciated sediment layers are still part of the core API, this should really be kicked out - e.g. when I explicitly request a specific API version like 1.4 I don't care about any features that have been deprecated in versions up to 1.4 and I don't care about any extensions that have been incorporated into the core API up until 1.4, so I'd really like to have them at least not show up in the Vulkan header so that code completion cannot sneak in outdated code (like EXT/KHR postfixes for things that have been moved into core). The current OpenGL-like sediment-layer-model (e.g. never remove old stuff) is extremely confusing when not following Vulkan development very closely since 2016, since there's often 5 ways to do the same thing, 3 of which are deprecated - but finding out whether a feature is deprecated is its own sidequest. What I actually wrestled with most was getting the outer frame-loop right without validation layer errors. I feel like this should be the next thing which the "Eye of Khronos" should focus on. All official tutorial/example code I've tried doesn't run without swapchain-sync-related validation errors on one or another configuration. Even this 'best practices' example code which demonstrates how to do the frame-loop scaffolding correctly produces valiation layer errors, so it's also quite useless: https://docs.vulkan.org/guide/latest/swapchain_semaphore_reuse.html https://docs.vulkan.org/guide/latest/swapchain_semaphore_reu... What's worse: different hardware/driver combos produce different validation layer errors (even in the swapchain-code which really shouldn't have different implementations across GPU vendors - e.g. shouldn't Khronos provide common reference code for those GPU-independent parts of drivers?). I wonder if there is actually any Vulkan code out there which is completely validation-layer-clean across all possible configs (I seriously doubt it). Also the VK_[EXT/KHR]_swapchain_maintenance1 extension which is supposed to fix all those little warts has such a low coverage that it's not worth supporting (but it should really be part of the core API by now - the extension is from 2019). Anyway... baby steps into the right direction, only a shame that it took a decade ;)
- reactordev 8mo ago
  Vulkan is by far the most powerful and the most pain in the ass API I've ever worked with. I agree on every point you just made.
  - jorvi 8mo ago
    Isn't the idea that 99% of people use a toolkit atop of Vulkan? Like, these days game devs just use Unreal Engine, which abstracts away having to work with the PS5 / PS4, DirectX 12, and Vulkan APIs. I imagine unless it's either for A. edification or B. very bespoke purpose code, you're not touching Vulkan.
    - m-schuetz 8mo ago
      Many people need something in-between heavy frameworks and engines or oppinionated wrappers with questionable support on top of Vulkan; and Vulkan itself. OpenGL served that purpose perfectly, but it's unfortunately abandoned.
      - quantummagic 8mo ago
        Isn't that what the Zink, ANGLE, or GLOVE projects meant to provide? Allow you to program in OpenGL, which is then automatically translated to Vulkan for you.
        m-schuetz 8mo ago
        I don't see the point of those when I can just directly use OpenGL. Any translation layer typically comes with limitations or issues. Also, I'm not that glued to OpenGL, I do think it's a terrible API, but there just isn't anything better yet. I wanted Vulkan to be something better, but I'm not going to use an API with entirely pointless complexity with zero performance benefits for my use cases.
        pjmlp 8mo ago
sho_hn 8mo ago
Are there any good Vulkan tutorials that are continuously updated to reflect these advancement and ease of use improvements? It's a similar challenge to the many different historical strata of C++ resources.
- jsheard 8mo ago
  https://howtovulkan.com https://howtovulkan.com is a recent one which targets the modern flavour of Vulkan that everything supports today. Well, all desktop hardware and drivers at least. God help you if you want to ship on Android.
- positron26 8mo ago
  Finding the optimal sub-language is about API coupling with client code, making a moving sweet spot for where bread & butter techniques live.
- dismalaf 8mo ago
  The one on Vulkan.org recently got updated to use dynamic rendering and a bunch of the newest features (plus modern C++, Slang instead of glsl, etc...). https://docs.vulkan.org/tutorial/latest/00_Introduction.html https://docs.vulkan.org/tutorial/latest/00_Introduction.html

by exDM69 8mo ago

flohofwoe 8mo ago

Having quite recently written a (still experimental) Vulkan backend for sokol_gfx.h, my impression is that starting with `VK_EXT_descriptor_buffer` (soon-ish to be replaced with `VK_EXT_descriptor_heap`), the "core API" is in pretty good shape now (with the remaining problem that all the outdated and depreciated sediment layers are still part of the core API, this should really be kicked out - e.g. when I explicitly request a specific API version like 1.4 I don't care about any features that have been deprecated in versions up to 1.4 and I don't care about any extensions that have been incorporated into the core API up until 1.4, so I'd really like to have them at least not show up in the Vulkan header so that code completion cannot sneak in outdated code (like EXT/KHR postfixes for things that have been moved into core). The current OpenGL-like sediment-layer-model (e.g. never remove old stuff) is extremely confusing when not following Vulkan development very closely since 2016, since there's often 5 ways to do the same thing, 3 of which are deprecated - but finding out whether a feature is deprecated is its own sidequest. What I actually wrestled with most was getting the outer frame-loop right without validation layer errors. I feel like this should be the next thing which the "Eye of Khronos" should focus on. All official tutorial/example code I've tried doesn't run without swapchain-sync-related validation errors on one or another configuration. Even this 'best practices' example code which demonstrates how to do the frame-loop scaffolding correctly produces valiation layer errors, so it's also quite useless: https://docs.vulkan.org/guide/latest/swapchain_semaphore_reuse.html https://docs.vulkan.org/guide/latest/swapchain_semaphore_reu... What's worse: different hardware/driver combos produce different validation layer errors (even in the swapchain-code which really shouldn't have different implementations across GPU vendors - e.g. shouldn't Khronos provide common reference code for those GPU-independent parts of drivers?). I wonder if there is actually any Vulkan code out there which is completely validation-layer-clean across all possible configs (I seriously doubt it). Also the VK_[EXT/KHR]_swapchain_maintenance1 extension which is supposed to fix all those little warts has such a low coverage that it's not worth supporting (but it should really be part of the core API by now - the extension is from 2019). Anyway... baby steps into the right direction, only a shame that it took a decade ;)

reactordev 8mo ago
Vulkan is by far the most powerful and the most pain in the ass API I've ever worked with. I agree on every point you just made.
- jorvi 8mo ago
  Isn't the idea that 99% of people use a toolkit atop of Vulkan? Like, these days game devs just use Unreal Engine, which abstracts away having to work with the PS5 / PS4, DirectX 12, and Vulkan APIs. I imagine unless it's either for A. edification or B. very bespoke purpose code, you're not touching Vulkan.
  - m-schuetz 8mo ago
    Many people need something in-between heavy frameworks and engines or oppinionated wrappers with questionable support on top of Vulkan; and Vulkan itself. OpenGL served that purpose perfectly, but it's unfortunately abandoned.
    - quantummagic 8mo ago
      Isn't that what the Zink, ANGLE, or GLOVE projects meant to provide? Allow you to program in OpenGL, which is then automatically translated to Vulkan for you.
      - m-schuetz 8mo ago
        I don't see the point of those when I can just directly use OpenGL. Any translation layer typically comes with limitations or issues. Also, I'm not that glued to OpenGL, I do think it's a terrible API, but there just isn't anything better yet. I wanted Vulkan to be something better, but I'm not going to use an API with entirely pointless complexity with zero performance benefits for my use cases.
        pjmlp 8mo ago

sho_hn 8mo ago

Are there any good Vulkan tutorials that are continuously updated to reflect these advancement and ease of use improvements? It's a similar challenge to the many different historical strata of C++ resources.

jsheard 8mo ago
https://howtovulkan.com https://howtovulkan.com is a recent one which targets the modern flavour of Vulkan that everything supports today. Well, all desktop hardware and drivers at least. God help you if you want to ship on Android.
positron26 8mo ago
Finding the optimal sub-language is about API coupling with client code, making a moving sweet spot for where bread & butter techniques live.
dismalaf 8mo ago
The one on Vulkan.org recently got updated to use dynamic rendering and a bunch of the newest features (plus modern C++, Slang instead of glsl, etc...). https://docs.vulkan.org/tutorial/latest/00_Introduction.html https://docs.vulkan.org/tutorial/latest/00_Introduction.html