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

101–110 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#101

Post by Animats »

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_E...

Re: Simplifying Vulkan one subsystem at a time

#102

Post by nicebyte »

m-schuetz wrote: post #86
socalgal2 wrote: post #66

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.

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.

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".

Re: Simplifying Vulkan one subsystem at a time

#103

Post by flohofwoe »

reactordev wrote: post #73
flohofwoe wrote: post #30

Earlier quoted context omitted.

> Isn't the idea that 99% of people use a toolkit atop of Vulkan? This idea creates a serious chicken-egg-problem. Two or three popular engine code bases sitting on top of Vulkan isn't enough 'critical mass' to get robust and high performance Vulkan drivers. When there's so little diversity in the code hammering on the Vulkan API it's unlikely that all the little bugs and performance problems lurking in the drivers w…

>”hardly any Windows games running on top of Vulkan” I run all my windows games on Vulkan. https://www.pcgamingwiki.com/wiki/List_of_Vulkan_games

280 games over 10 years really isn't impressive (2.5x less than even D3D8 which was an unpopular 'inbetween' D3D version and only relevant for about 2 years). D3D12 (890 games) isn't great either when compared to D3D11 (4.6k) or D3D9 (3.3k), it really demonstrates what a massive failure the modern 3D APIs are for real-world usage :/

I don't think those lists are complete, but they seem to show the right relative amount of 3D API usage across PC games.

Re: Simplifying Vulkan one subsystem at a time

#104

Post by nicebyte »

Animats wrote: post #101

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.…

> 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.

Re: Simplifying Vulkan one subsystem at a time

#105

Post by m-schuetz »

nicebyte wrote: post #102
m-schuetz wrote: post #86

Earlier quoted context omitted.

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.

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".

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.

Re: Simplifying Vulkan one subsystem at a time

#106

Post by reactordev »

flohofwoe wrote: post #103
reactordev wrote: post #73

Earlier quoted context omitted.

>”hardly any Windows games running on top of Vulkan” I run all my windows games on Vulkan. https://www.pcgamingwiki.com/wiki/List_of_Vulkan_games

280 games over 10 years really isn't impressive (2.5x less than even D3D8 which was an unpopular 'inbetween' D3D version and only relevant for about 2 years). D3D12 (890 games) isn't great either when compared to D3D11 (4.6k) or D3D9 (3.3k), it really demonstrates what a massive failure the modern 3D APIs are for real-world usage :/ I don't think those lists are complete, but they seem to show the right relative amou…

I’m just pointing out that Vulkan is supported on all major modern engines, internal and public. Some also go so far as to do DX12 (fine, it’s a similar feeling API) but what’s really amazing is taking all of those games that run on OpenGL, DirectX, etc and forcing them to run on Vulkan…

Proton is amazing and Wine project deserves your support.

Re: Simplifying Vulkan one subsystem at a time

#107

Post by gspr »

jauntywundrkind wrote: post #26
adithyassekhar wrote: post #22

Earlier quoted context omitted.

Which one would you recommend for regular users and power users?

Debian/testing, with stable pinned on at low priority. It slows down for a couple months around release, but generally provides pretty reliable & up to date experience with a very good OS. Dance dance the red spiral.

A stable-testing mix is quite exotic. What are you trying to achieve here?

Re: Simplifying Vulkan one subsystem at a time

#108

Post by flohofwoe »

pjmlp wrote: post #89
socalgal2 wrote: post #66

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.

Same with DirectX, if only COM actually had better tooling, instead of pick your adventure C++ framework, or first class support for .NET.

DXGI+D3D11 via C is actually fine and is close or even lower than Metalv1 when it comes to 'lines of code needed to get a triangle on screen". D3D12 is more boilerplate-heavy, but still not as bad as Vulkan.

Re: Simplifying Vulkan one subsystem at a time

#109

Post by nicebyte »

m-schuetz wrote: post #105
nicebyte wrote: post #102

Earlier quoted context omitted.

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".

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…

> 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.

Re: Simplifying Vulkan one subsystem at a time

#110

Post by Animats »

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.

NVidia says no new gamer GPUs in 2026, and increasing prices through 2030. They're too focused on enterprise AI machines.
Post reply on HN