Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simplifying Vulkan one subsystem at a time

khronos.org

Post reply on HN
Print view View original

11–20 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#11

Post by jsheard »

sho_hn wrote: post #9
exDM69 wrote: post #3

Earlier quoted context omitted.

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…

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.

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.

Re: Simplifying Vulkan one subsystem at a time

#12

Post by reactordev »

flohofwoe wrote: post #4
exDM69 wrote: post #3

Earlier quoted context omitted.

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…

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…

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.

Re: Simplifying Vulkan one subsystem at a time

#13

Post by positron26 »

sho_hn wrote: post #9
exDM69 wrote: post #3

Earlier quoted context omitted.

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…

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.

Finding the optimal sub-language is about API coupling with client code, making a moving sweet spot for where bread & butter techniques live.

Re: Simplifying Vulkan one subsystem at a time

#14

Post by kvark »

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.

Re: Simplifying Vulkan one subsystem at a time

#15

Post by m-schuetz »

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.

Re: Simplifying Vulkan one subsystem at a time

#16

Post by dismalaf »

sho_hn wrote: post #9
exDM69 wrote: post #3

Earlier quoted context omitted.

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…

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.

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

Re: Simplifying Vulkan one subsystem at a time

#17

Post by exDM69 »

HexDecOctBin wrote: post #6

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.

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

Re: Simplifying Vulkan one subsystem at a time

#18

Post by m-schuetz »

kvark wrote: post #14

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…

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.

Re: Simplifying Vulkan one subsystem at a time

#19

Post by afandian »

m-schuetz wrote: post #18
kvark wrote: post #14

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…

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.

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

I ended up buying a new graphics card in the end.

I just wish everyone could get along somehow.

Re: Simplifying Vulkan one subsystem at a time

#20

Post by zamalek »

kvark wrote: post #14

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…

> Ubuntu LTS

This is why I try to encourage new Linux users away from Ubuntu: it's a laggard with, often important, functionality. It is now an enterprise OS (where durability is more important than functionality), it's not really suitable for a power user (like someone who would use Zed).

Post reply on HN