13 ms·

Simplifying Vulkan one subsystem at a time

274 points by amazari 7mo ago

hmry 7mo ago
I'm really enjoying these changes. Going from render passes to dynamic rendering really simplified my code. I wonder how this new feature compares to existing bindless rendering. From the linked video, "Feature parity with OpenCL" is the thing I'm most looking forward to.
- exDM69 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
  - sho_hn 7mo 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 7mo 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 7mo 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 7mo 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
lucastytthhh 7mo ago
[flagged]
HexDecOctBin 7mo ago
I personally just switched to using push descriptors everywhere. On desktops, the real world limits are high enough that it end up working out fine and you get a nice immediate mode API like OpenGL.
- exDM69 7mo ago
  That's the right way to go for simple use cases and especially getting started on a new project.
openclawagent13 7mo ago
[dead]
pixelpoet 7mo ago
I would like to / am "supposed to" use Vulkan but it's a massive pain coming from OpenCL, with all kinds of issues that need safe handling which simply don't come from OpenCL workloads. Everyone keeps telling me OpenCL is deprecated (which is true, although it's also true that it continues to work superbly in 2026) but there isn't a good / official OpenCL to Vulkan wrapper out there to justify it for what I do.
- tormeh 7mo ago
  I think there's Rusticl for this, although it may not be ready yet.
pjmlp 7mo ago
At least they are making an effort to correct the extension spaghetti, already worse than OpenGL. Addiitionally most of these fixes aren't coming into Android, now getting WebGPU for Java/Kotlin[0] after so many refused to move away from OpenGL ES, and naturally any card not lucky to get new driver releases. Still, better now than never. [0] - https://developer.android.com/jetpack/androidx/releases/webgpu https://developer.android.com/jetpack/androidx/releases/webg...
- kllrnohj 7mo ago
  [flagged]
  - pjmlp 7mo ago
    Thanks for showing the audience the lack of experience with Vulkan drivers on Android.
  - imtringued 7mo ago
    The chain for GPU driver updates on Android phones is incredibly long. Google > Phone Vendor > SoC Vendor > Arm > SoC Vendor > Phone Vendor > Android Update and that is the happy case. The general case looks more like this: Google > Phone Vendor > SoC Vendor > "Have you considered buying a new SoC?"
    - kllrnohj 7mo ago
      long is different from won't come
- tadfisher 7mo ago
  Bizarre take. Notice how that WebGPU is an AndroidX library? That means WebGPU API support is built into apps via that library and runs on top of the system's Vulkan or OpenGL ES API. Do you work for Google or an Android OEM? If not, you have no basis to make the claim that Android will cease updating Vulkan API support.
  - 7mo ago
kvark 7mo ago
The main problem with Vulkan isn't the programming model or the lack of features. These are tackled by Khronos. The problem is with coverage and update distribution. It's all over the place! If you develop general purpose software (like Zed), you can't assume that even the basic things like dynamic rendering are supported uniformly. There are always weird systems with old drivers (looking at Ubuntu 22 LTS), hardware vendors abandoning and forcefully deprecating the working hardware, and of course driver bugs... So, by the time I'm going to be able to rely on the new shiny descriptor heap/buffer features, I'll have more gray hair and other things on the horizon.
- m-schuetz 7mo ago
  Tbh, we should more readily abandon GPU vendors that refuse to go with the times. If we cater to them for too long, they have no reason to adapt.
  - afandian 7mo ago
    I had a relatively recent graphics card (5 years old perhaps?). I don't care about 3D or games, or whatever. So I was sad not to be able to run a text editor (let's be honest, Zed is nice but it's just displaying text). And somehow the non-accelerated version is eating 24 cores. Just for text. https://github.com/zed-industries/zed/discussions/23623 https://github.com/zed-industries/zed/discussions/23623 I ended up buying a new graphics card in the end. I just wish everyone could get along somehow.
    - ronsor 7mo ago
      The fact that we need advanced GPU acceleration for a text editor is concerning.
      - ianlevesque 7mo ago
        Text editor developers get bored too!
      - deleted 7mo ago
m-schuetz 7mo ago
I suspect we are only 5-10 years away until Vulkan is finaly usable. There are so many completely needlessly complex things, or things that should have an easy-path for the common case. BDA, dynamic rendering and shader objects almost make Vulkan bearable. What's still sorely missing is a single-line device malloc, a default queue that can be used without ever touching the queue family API, and an entirely descriptor-free code path. The latter would involve making the NV bindless extension the standard which simply gives you handles to textures, without making you manage descriptor buffers/sets/heaps. Maybe also put an easy-path for synchronization on that list and making the explicit API optional. Until then I'll keep enjoying OpenGL 4.6, which already had BDA with c-style pointer syntax in glsl shaders since 2010 (NV_shader_buffer_load), and which allows hassle-free buffer allocation and descriptor-set-free bindless textures.
- bvjgkbl 7mo ago
  I use Vulkan on a daily basis. Some examples: - with DXVK to play games - with llama.cpp to run local LLMs Vulkan is already everywhere, from games to AI.
jauntywundrkind 7mo ago
How are folks feeling about WebGPU these days? Once Vulkan is finally in good order, descriptor_heap and others, I really really hope we can get a WebGPU.next. Where are we at with the "what's next for webgpu" post, from 5 quarters ago? https://developer.chrome.com/blog/next-for-webgpu https://developer.chrome.com/blog/next-for-webgpu https://news.ycombinator.com/item?id=42209272 https://news.ycombinator.com/item?id=42209272
- m-schuetz 7mo ago
  WebGPU is kinda meh, a 2010s graphic programmers vision of a modern API. It follows Vulkan 1.0, and while Vulkan is finally getting rid of most of the mess like pipelines, WebGPU went all in. It's surprisingly cumbersome to bind stuff to shaders, and everything is static and has to be hashed&cached, which sucks for streaming/LOD systems. Nowadays you can easily pass arbitrary amounts of buffers and entire scene descriptions via GPU memory pointers to OpenGL, Vulkan, CUDA, etc. with BDA and change them dynamically each frame. But not in WebGPU which does not support BDA und is unlikely to support it anytime soon. It's also disappointing that OpenGL 4.6, released in 2017, is a decade ahead of WebGPU.
  - kllrnohj 7mo ago
    WebGPU has the problem of needing to handle the lowest common denominator (so GLES 3 if not GLES 2 because of low end mobile), and also needing to deal with Apple's refusal to do anything with even a hint of Khronos (hence why no SPIR-V even though literally everything else including DirectX has adopted it) Web graphics have never and will never be cutting edge, they can't as they have to sit on top of browsers that have to already have those features available to it. It can only ever build on top of something lower level. That's not inherently bad, not everything needs cutting edge, but "it's outdated" is also just inherently going to be always true.
    - m-schuetz 7mo ago
      I understand not being cutting-edge. But having a feature-set from 2010 is...not great. Also, some things could have easily be done different and then be implemented as efficient as a particular backend allows. Like pipelines. Just don't do pipelines at all. A web graphics API does not need them, WebGL worked perfectly fine without them. The WebGPU backends can use them if necessary, or not use them if more modern systems don't require them anymore. But now we're locked-in to a needlessly cumbersome and outdated way of doing things in WebGPU. Similarly, WebGPU could have done without that static binding mess. Just do something like commandBuffer.draw(shader, vertexBuffer, indexBuffer, texture, ...) and automatically connect the call with the shader arguments, like CUDA does. The backend can then create all that binding nonsense if necessary, or not if a newer backend does not need it anymore.
jabl 7mo ago
Does this evolution of the Vulkan API get closer to the model explained in https://www.sebastianaaltonen.com/blog/no-graphics-api https://www.sebastianaaltonen.com/blog/no-graphics-api which we discussed in https://news.ycombinator.com/item?id=46293062 https://news.ycombinator.com/item?id=46293062 ?
- rkevingibson 7mo ago
  Yes, you can get very close to that API with this extension + existing Vulkan extensions. The main difference is that you still kind of need opaque buffer and texture objects instead of raw pointers, but you can get GPU pointers for them and still work with those. In theory I think you could do the malloc API design there but it's fairly unintuitive in Vulkan and you'd still need VkBuffers internally even if you didn't expose them in a wrapper layer. I've got a (not yet ready for public) wrapper on Vulkan that mostly matches this blog post, and so far it's been a really lovely way to do graphics programming. The main thing that's not possible at all on top of Vulkan is his signals API, which I would enjoy seeing - it could be done if timeline semaphores could be waited on/signalled inside a command buffer, rather than just on submission boundaries. Not sure how feasible that is with existing hardware though.
- flohofwoe 7mo ago
  It's a baby-step in this direction, e.g. from Seb's article: > Vulkan’s VK_EXT_descriptor_buffer (https://www.khronos.org/blog/vk-ext-descriptor-buffer https://www.khronos.org/blog/vk-ext-descriptor-buffer) extension (2022) is similar to my proposal, allowing direct CPU and GPU write. It is supported by most vendors, but unfortunately is not part of the Vulkan 1.4 core spec. The new `VK_EXT_descriptor_heap` extension described in the Khronos post is a replacement for `VK_EXT_descriptor_buffer` which fixes some problems but otherwise is the same basic idea (e.g. "descriptors are just memory").
tonis2 7mo ago
I wish they would just allow us to push everything to GPU as buffer pointers, like buffer_device address extension allows you to, and then reconstruct the data to your required format via shaders. The GPU programming seems to be both super low level, but also high level, cause textures and descriptors need these ultra specific data format's, and then the way you construct and upload those formats are very complicated and change all the time. Is there really no way to simplify this ? Regular vertex data was supposed to be strictly pre formatted in pipeline too, util it was not suddenly, and now we can just give the shader a `device_address`extension memory pointer and construct the data from that.
- jsheard 7mo ago
  Relevant: Descriptors are Hard from XDC 2025 - https://www.youtube.com/watch?v=TpwjJdkg2RE https://www.youtube.com/watch?v=TpwjJdkg2RE Even on modern hardware there's still a lot of architectural differences to reconcile at the API level.
- softfalcon 7mo ago
  I also want what you're describing. It seems like the ideal "data-in-out" pipeline for purely compute based shaders. I've brought it up several times when talking with folks who work down in the chip level for optimizing these operations and all I can say is, there are a lot of unforeseen complications to what we're suggesting. It's not that we can't have a GPU that does these things, it's apparently more of a combination of previous and current architectural decisions that don't want that. For instance, an nVidia GPU is focused on providing the hardware optimizations necessary to do either LLM compute or graphics acceleration, both essentially proprietary technologies. The proprietariness isn't why it's obtuse though, you can make a chip go super-duper fast for specific tasks, or more general for all kinds of tasks. Somewhere, folks are making a tradeoff of backwards compatibility and supporting new hardware accelerated tasks. Neither of these are "general purpose compute and data flow" focuses. As such, you get the GPU that only sorta is configurable for what you want to do. Which in my opinion explains your "GPU programming seems to be both super low level, but also high level" comment. That's been my experience. I still think what you're suggesting is a great idea and would make GPU's a more open compute platform for a wider variety of tasks, while also simplifying things a lot.
socalgal2 7mo ago
Vulkan takes like 600+ lines to do what Metal does in 50. I'm sure the comments will be all excuses and whys but they're all nonsense. It's just a poorly thought out API.
- m-schuetz 7mo ago
  Agreed. It has way too much completely unnecessary verbosity. Like, why the hell does it take 30 lines to allocate memory rather than one single malloc.
  - nicebyte 7mo ago
    just use the vma library. the low level memory allocation interface is for those who care to have precise control over allocations. vma has shipped in production software and is a safe choice for those who want to "just allocate memory".
    - m-schuetz 7mo ago
      Nah, I know about VMA and it's a poor bandaid. I want a single-line malloc with zero care about usage flags and which only produces one single pointer value, because that's all that's needed in pretty much all of my use cases. VMA does not provide that. And Vulkans unnecessary complexity doesn't stop at that issue, there are plenty of follow-up issues that I also have no intention of dealing with. Instead, I'll just use Cuda which doesn't bother me with useless complexity until I actually opt-in to it when it's time to optimize. Cuda allows to easily get stuff done first then check the more complex stuff to optimize, unlike Vulkan which unloads the entire complexity on you right from the start, before you have any chance to figure out what to do.
      - nicebyte 7mo ago
        > I want a single-line malloc with zero care about usage flags and which only produces one single pointer value That's not realistic on non-UMA systems. I doubt you want to go over PCIe every time you sample a texture, so the allocator has to know what you're allocating memory _for_. Even with CUDA you have to do that. And even with unified memory, only the implementation knows exactly how much space is needed for a texture with a given format and configuration (e.g. due to different alignment requirements and such). "just" malloc-ing gpu memory sounds nice and would be nice, but given many vendors and many devices the complexity becomes irreducible. If your only use case is compute on nvidia chips, you shouldn't be using vulkan in the first place.
sxzygz 7mo ago
Uuugh, graphics. So many smart people expending great energy to look busy while doing nothing particularly profound. Graphics people, here is what you need to do. 1) Figure out a machine abstraction. 2) Figure out an abstraction for how these machines communicate with each other and the cpu on a shared memory bus. 3) Write a binary spec for code for this abstract machine. 4) Compilers target this abstract machine. 5) Programs submit code to driver for AoT compilation, and cache results. 6) Driver has some linker and dynamic module loading/unloading capability. 7) Signal the driver to start that code. AMD64, ARM, and RISC-V are all basically differing binary specs for a C-machine+MMU+MMIO compute abstraction. Figure out your machine abstraction and let us normies write code that’s accelerated without having to throw the baby out with the bathwater ever few years. Oh yes, give us timing information so we can adapt workload as necessary to achieve soft real-time scheduling on hardware with differing performance.
- M95D 7mo ago
  It sounds like webgl + wasm.
- nicebyte 7mo ago
  some of this is what's khronos standards are theoretically supposed to achieve. surprise, it's very difficult to do across many hw vendors and classes of devices. it's not a coincidence that metal is much easier to program for. maybe consider joining khronos since you apparently know exactly how to achieve this very simple goal...
  - flohofwoe 7mo ago
    > it's not a coincidence that metal is much easier to program for Tbf, Metal also works on non-Apple GPUs and with only minimal additional hints to manage resources in non-unified memory.
- flohofwoe 7mo ago
  Wow, you should get NVIDIA, AMD and Intel on the phone ASAP! Really strange that they didn't come up with such a simple and straightforward idea in the last 3 decades ;)
janlucien 7mo ago
[dead]
Animats 7mo ago
Not sure if this is an "oh, no" event. So this goes into Vulkan. Then it has to ship with the OS. Then it has to go into intermediate layers such as WGPU. Which will probably have to support both old and new mode. Then it has to go into renderers. Which will probably have to support both old and new mode. Maybe at the top of the renderer you can't tell if you're in old or new mode, but it will probably leak through. In that case game engines have to know about this. Which will cause churn in game code. And Apple will do something different, in Metal. Unreal Engine and Unity have the staffs to handle this, but few others do. The Vulkan-based renderers which use Vulkan concurrency to get performance OpenGL can't deliver are few. Probably only Unreal Engine and Unity really exploit Vulkan properly. Here's the top level of the Vulkan changes.[1] It doesn't look simple. (I'm mostly grumbling because the difficulty and churn in Vulkan/WGPU has resulted in three abandoned renderers in Rust land through developer burnout. I'm a user of renderers, and would like them to Just Work.) [1] https://docs.vulkan.org/refpages/latest/refpages/source/VK_EXT_descriptor_heap.html https://docs.vulkan.org/refpages/latest/refpages/source/VK_E...
- nicebyte 7mo ago
  > Not sure if this is an "oh, no" event. it's not. descriptor sets are realistically never getting deprecated. old code doesn't have to be rewritten if it works. there's no point. if you're doing bindless (which you most certainly arent if you're still stuck with descriptor sets) this offers a better way of handling that. if you care to upgrade your descriptor set based path to use heaps, this extension offers a very nice pathway to doing so _without having to even recompile shaders_. for new/future code, this is a solid improvement. if you're happy where you are with your renderer, there isn't a need to do anything.
  - p_l 7mo ago
    And apparently if you do mobile you stay away from big chunk of dynamic rendering and use Vulkan 1.0 style renderpasses... or you leave performance on the floor (based on guidelines from various mobile GPU vendors)
    - 7mo ago

274 points by amazari 7mo ago

hmry 7mo ago

I'm really enjoying these changes. Going from render passes to dynamic rendering really simplified my code. I wonder how this new feature compares to existing bindless rendering. From the linked video, "Feature parity with OpenCL" is the thing I'm most looking forward to.

exDM69 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
- sho_hn 7mo 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 7mo 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 7mo 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 7mo 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

lucastytthhh 7mo ago

[flagged]

HexDecOctBin 7mo ago

I personally just switched to using push descriptors everywhere. On desktops, the real world limits are high enough that it end up working out fine and you get a nice immediate mode API like OpenGL.

exDM69 7mo ago
That's the right way to go for simple use cases and especially getting started on a new project.

openclawagent13 7mo ago

[dead]

pixelpoet 7mo ago

I would like to / am "supposed to" use Vulkan but it's a massive pain coming from OpenCL, with all kinds of issues that need safe handling which simply don't come from OpenCL workloads. Everyone keeps telling me OpenCL is deprecated (which is true, although it's also true that it continues to work superbly in 2026) but there isn't a good / official OpenCL to Vulkan wrapper out there to justify it for what I do.

tormeh 7mo ago
I think there's Rusticl for this, although it may not be ready yet.

pjmlp 7mo ago

At least they are making an effort to correct the extension spaghetti, already worse than OpenGL. Addiitionally most of these fixes aren't coming into Android, now getting WebGPU for Java/Kotlin[0] after so many refused to move away from OpenGL ES, and naturally any card not lucky to get new driver releases. Still, better now than never. [0] - https://developer.android.com/jetpack/androidx/releases/webgpu https://developer.android.com/jetpack/androidx/releases/webg...

kllrnohj 7mo ago
[flagged]
- pjmlp 7mo ago
  Thanks for showing the audience the lack of experience with Vulkan drivers on Android.
- imtringued 7mo ago
  The chain for GPU driver updates on Android phones is incredibly long. Google > Phone Vendor > SoC Vendor > Arm > SoC Vendor > Phone Vendor > Android Update and that is the happy case. The general case looks more like this: Google > Phone Vendor > SoC Vendor > "Have you considered buying a new SoC?"
  - kllrnohj 7mo ago
    long is different from won't come
tadfisher 7mo ago
Bizarre take. Notice how that WebGPU is an AndroidX library? That means WebGPU API support is built into apps via that library and runs on top of the system's Vulkan or OpenGL ES API. Do you work for Google or an Android OEM? If not, you have no basis to make the claim that Android will cease updating Vulkan API support.
- 7mo ago

kvark 7mo ago

The main problem with Vulkan isn't the programming model or the lack of features. These are tackled by Khronos. The problem is with coverage and update distribution. It's all over the place! If you develop general purpose software (like Zed), you can't assume that even the basic things like dynamic rendering are supported uniformly. There are always weird systems with old drivers (looking at Ubuntu 22 LTS), hardware vendors abandoning and forcefully deprecating the working hardware, and of course driver bugs... So, by the time I'm going to be able to rely on the new shiny descriptor heap/buffer features, I'll have more gray hair and other things on the horizon.

m-schuetz 7mo ago
Tbh, we should more readily abandon GPU vendors that refuse to go with the times. If we cater to them for too long, they have no reason to adapt.
- afandian 7mo ago
  I had a relatively recent graphics card (5 years old perhaps?). I don't care about 3D or games, or whatever. So I was sad not to be able to run a text editor (let's be honest, Zed is nice but it's just displaying text). And somehow the non-accelerated version is eating 24 cores. Just for text. https://github.com/zed-industries/zed/discussions/23623 https://github.com/zed-industries/zed/discussions/23623 I ended up buying a new graphics card in the end. I just wish everyone could get along somehow.
  - ronsor 7mo ago
    The fact that we need advanced GPU acceleration for a text editor is concerning.
    - ianlevesque 7mo ago
      Text editor developers get bored too!
    - deleted 7mo ago

m-schuetz 7mo ago

I suspect we are only 5-10 years away until Vulkan is finaly usable. There are so many completely needlessly complex things, or things that should have an easy-path for the common case. BDA, dynamic rendering and shader objects almost make Vulkan bearable. What's still sorely missing is a single-line device malloc, a default queue that can be used without ever touching the queue family API, and an entirely descriptor-free code path. The latter would involve making the NV bindless extension the standard which simply gives you handles to textures, without making you manage descriptor buffers/sets/heaps. Maybe also put an easy-path for synchronization on that list and making the explicit API optional. Until then I'll keep enjoying OpenGL 4.6, which already had BDA with c-style pointer syntax in glsl shaders since 2010 (NV_shader_buffer_load), and which allows hassle-free buffer allocation and descriptor-set-free bindless textures.

bvjgkbl 7mo ago
I use Vulkan on a daily basis. Some examples: - with DXVK to play games - with llama.cpp to run local LLMs Vulkan is already everywhere, from games to AI.

jauntywundrkind 7mo ago

How are folks feeling about WebGPU these days? Once Vulkan is finally in good order, descriptor_heap and others, I really really hope we can get a WebGPU.next. Where are we at with the "what's next for webgpu" post, from 5 quarters ago? https://developer.chrome.com/blog/next-for-webgpu https://developer.chrome.com/blog/next-for-webgpu https://news.ycombinator.com/item?id=42209272 https://news.ycombinator.com/item?id=42209272

m-schuetz 7mo ago
WebGPU is kinda meh, a 2010s graphic programmers vision of a modern API. It follows Vulkan 1.0, and while Vulkan is finally getting rid of most of the mess like pipelines, WebGPU went all in. It's surprisingly cumbersome to bind stuff to shaders, and everything is static and has to be hashed&cached, which sucks for streaming/LOD systems. Nowadays you can easily pass arbitrary amounts of buffers and entire scene descriptions via GPU memory pointers to OpenGL, Vulkan, CUDA, etc. with BDA and change them dynamically each frame. But not in WebGPU which does not support BDA und is unlikely to support it anytime soon. It's also disappointing that OpenGL 4.6, released in 2017, is a decade ahead of WebGPU.
- kllrnohj 7mo ago
  WebGPU has the problem of needing to handle the lowest common denominator (so GLES 3 if not GLES 2 because of low end mobile), and also needing to deal with Apple's refusal to do anything with even a hint of Khronos (hence why no SPIR-V even though literally everything else including DirectX has adopted it) Web graphics have never and will never be cutting edge, they can't as they have to sit on top of browsers that have to already have those features available to it. It can only ever build on top of something lower level. That's not inherently bad, not everything needs cutting edge, but "it's outdated" is also just inherently going to be always true.
  - m-schuetz 7mo ago
    I understand not being cutting-edge. But having a feature-set from 2010 is...not great. Also, some things could have easily be done different and then be implemented as efficient as a particular backend allows. Like pipelines. Just don't do pipelines at all. A web graphics API does not need them, WebGL worked perfectly fine without them. The WebGPU backends can use them if necessary, or not use them if more modern systems don't require them anymore. But now we're locked-in to a needlessly cumbersome and outdated way of doing things in WebGPU. Similarly, WebGPU could have done without that static binding mess. Just do something like commandBuffer.draw(shader, vertexBuffer, indexBuffer, texture, ...) and automatically connect the call with the shader arguments, like CUDA does. The backend can then create all that binding nonsense if necessary, or not if a newer backend does not need it anymore.

jabl 7mo ago

Does this evolution of the Vulkan API get closer to the model explained in https://www.sebastianaaltonen.com/blog/no-graphics-api https://www.sebastianaaltonen.com/blog/no-graphics-api which we discussed in https://news.ycombinator.com/item?id=46293062 https://news.ycombinator.com/item?id=46293062 ?

rkevingibson 7mo ago
Yes, you can get very close to that API with this extension + existing Vulkan extensions. The main difference is that you still kind of need opaque buffer and texture objects instead of raw pointers, but you can get GPU pointers for them and still work with those. In theory I think you could do the malloc API design there but it's fairly unintuitive in Vulkan and you'd still need VkBuffers internally even if you didn't expose them in a wrapper layer. I've got a (not yet ready for public) wrapper on Vulkan that mostly matches this blog post, and so far it's been a really lovely way to do graphics programming. The main thing that's not possible at all on top of Vulkan is his signals API, which I would enjoy seeing - it could be done if timeline semaphores could be waited on/signalled inside a command buffer, rather than just on submission boundaries. Not sure how feasible that is with existing hardware though.
flohofwoe 7mo ago
It's a baby-step in this direction, e.g. from Seb's article: > Vulkan’s VK_EXT_descriptor_buffer (https://www.khronos.org/blog/vk-ext-descriptor-buffer https://www.khronos.org/blog/vk-ext-descriptor-buffer) extension (2022) is similar to my proposal, allowing direct CPU and GPU write. It is supported by most vendors, but unfortunately is not part of the Vulkan 1.4 core spec. The new `VK_EXT_descriptor_heap` extension described in the Khronos post is a replacement for `VK_EXT_descriptor_buffer` which fixes some problems but otherwise is the same basic idea (e.g. "descriptors are just memory").

tonis2 7mo ago

I wish they would just allow us to push everything to GPU as buffer pointers, like buffer_device address extension allows you to, and then reconstruct the data to your required format via shaders. The GPU programming seems to be both super low level, but also high level, cause textures and descriptors need these ultra specific data format's, and then the way you construct and upload those formats are very complicated and change all the time. Is there really no way to simplify this ? Regular vertex data was supposed to be strictly pre formatted in pipeline too, util it was not suddenly, and now we can just give the shader a `device_address`extension memory pointer and construct the data from that.

jsheard 7mo ago
Relevant: Descriptors are Hard from XDC 2025 - https://www.youtube.com/watch?v=TpwjJdkg2RE https://www.youtube.com/watch?v=TpwjJdkg2RE Even on modern hardware there's still a lot of architectural differences to reconcile at the API level.
softfalcon 7mo ago
I also want what you're describing. It seems like the ideal "data-in-out" pipeline for purely compute based shaders. I've brought it up several times when talking with folks who work down in the chip level for optimizing these operations and all I can say is, there are a lot of unforeseen complications to what we're suggesting. It's not that we can't have a GPU that does these things, it's apparently more of a combination of previous and current architectural decisions that don't want that. For instance, an nVidia GPU is focused on providing the hardware optimizations necessary to do either LLM compute or graphics acceleration, both essentially proprietary technologies. The proprietariness isn't why it's obtuse though, you can make a chip go super-duper fast for specific tasks, or more general for all kinds of tasks. Somewhere, folks are making a tradeoff of backwards compatibility and supporting new hardware accelerated tasks. Neither of these are "general purpose compute and data flow" focuses. As such, you get the GPU that only sorta is configurable for what you want to do. Which in my opinion explains your "GPU programming seems to be both super low level, but also high level" comment. That's been my experience. I still think what you're suggesting is a great idea and would make GPU's a more open compute platform for a wider variety of tasks, while also simplifying things a lot.

socalgal2 7mo ago

Vulkan takes like 600+ lines to do what Metal does in 50. I'm sure the comments will be all excuses and whys but they're all nonsense. It's just a poorly thought out API.

m-schuetz 7mo ago
Agreed. It has way too much completely unnecessary verbosity. Like, why the hell does it take 30 lines to allocate memory rather than one single malloc.
- nicebyte 7mo ago
  just use the vma library. the low level memory allocation interface is for those who care to have precise control over allocations. vma has shipped in production software and is a safe choice for those who want to "just allocate memory".
  - m-schuetz 7mo ago
    Nah, I know about VMA and it's a poor bandaid. I want a single-line malloc with zero care about usage flags and which only produces one single pointer value, because that's all that's needed in pretty much all of my use cases. VMA does not provide that. And Vulkans unnecessary complexity doesn't stop at that issue, there are plenty of follow-up issues that I also have no intention of dealing with. Instead, I'll just use Cuda which doesn't bother me with useless complexity until I actually opt-in to it when it's time to optimize. Cuda allows to easily get stuff done first then check the more complex stuff to optimize, unlike Vulkan which unloads the entire complexity on you right from the start, before you have any chance to figure out what to do.
    - nicebyte 7mo ago
      > I want a single-line malloc with zero care about usage flags and which only produces one single pointer value That's not realistic on non-UMA systems. I doubt you want to go over PCIe every time you sample a texture, so the allocator has to know what you're allocating memory _for_. Even with CUDA you have to do that. And even with unified memory, only the implementation knows exactly how much space is needed for a texture with a given format and configuration (e.g. due to different alignment requirements and such). "just" malloc-ing gpu memory sounds nice and would be nice, but given many vendors and many devices the complexity becomes irreducible. If your only use case is compute on nvidia chips, you shouldn't be using vulkan in the first place.

sxzygz 7mo ago

Uuugh, graphics. So many smart people expending great energy to look busy while doing nothing particularly profound. Graphics people, here is what you need to do. 1) Figure out a machine abstraction. 2) Figure out an abstraction for how these machines communicate with each other and the cpu on a shared memory bus. 3) Write a binary spec for code for this abstract machine. 4) Compilers target this abstract machine. 5) Programs submit code to driver for AoT compilation, and cache results. 6) Driver has some linker and dynamic module loading/unloading capability. 7) Signal the driver to start that code. AMD64, ARM, and RISC-V are all basically differing binary specs for a C-machine+MMU+MMIO compute abstraction. Figure out your machine abstraction and let us normies write code that’s accelerated without having to throw the baby out with the bathwater ever few years. Oh yes, give us timing information so we can adapt workload as necessary to achieve soft real-time scheduling on hardware with differing performance.

M95D 7mo ago
It sounds like webgl + wasm.
nicebyte 7mo ago
some of this is what's khronos standards are theoretically supposed to achieve. surprise, it's very difficult to do across many hw vendors and classes of devices. it's not a coincidence that metal is much easier to program for. maybe consider joining khronos since you apparently know exactly how to achieve this very simple goal...
- flohofwoe 7mo ago
  > it's not a coincidence that metal is much easier to program for Tbf, Metal also works on non-Apple GPUs and with only minimal additional hints to manage resources in non-unified memory.
flohofwoe 7mo ago
Wow, you should get NVIDIA, AMD and Intel on the phone ASAP! Really strange that they didn't come up with such a simple and straightforward idea in the last 3 decades ;)

janlucien 7mo ago

[dead]

Animats 7mo ago

Not sure if this is an "oh, no" event. So this goes into Vulkan. Then it has to ship with the OS. Then it has to go into intermediate layers such as WGPU. Which will probably have to support both old and new mode. Then it has to go into renderers. Which will probably have to support both old and new mode. Maybe at the top of the renderer you can't tell if you're in old or new mode, but it will probably leak through. In that case game engines have to know about this. Which will cause churn in game code. And Apple will do something different, in Metal. Unreal Engine and Unity have the staffs to handle this, but few others do. The Vulkan-based renderers which use Vulkan concurrency to get performance OpenGL can't deliver are few. Probably only Unreal Engine and Unity really exploit Vulkan properly. Here's the top level of the Vulkan changes.[1] It doesn't look simple. (I'm mostly grumbling because the difficulty and churn in Vulkan/WGPU has resulted in three abandoned renderers in Rust land through developer burnout. I'm a user of renderers, and would like them to Just Work.) [1] https://docs.vulkan.org/refpages/latest/refpages/source/VK_EXT_descriptor_heap.html https://docs.vulkan.org/refpages/latest/refpages/source/VK_E...

nicebyte 7mo ago
> Not sure if this is an "oh, no" event. it's not. descriptor sets are realistically never getting deprecated. old code doesn't have to be rewritten if it works. there's no point. if you're doing bindless (which you most certainly arent if you're still stuck with descriptor sets) this offers a better way of handling that. if you care to upgrade your descriptor set based path to use heaps, this extension offers a very nice pathway to doing so _without having to even recompile shaders_. for new/future code, this is a solid improvement. if you're happy where you are with your renderer, there isn't a need to do anything.
- p_l 7mo ago
  And apparently if you do mobile you stay away from big chunk of dynamic rendering and use Vulkan 1.0 style renderpasses... or you leave performance on the floor (based on guidelines from various mobile GPU vendors)
  - 7mo ago