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

21–30 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#21

Post by jorvi »

reactordev wrote: post #12
flohofwoe wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: Simplifying Vulkan one subsystem at a time

#22

Post by adithyassekhar »

zamalek wrote: post #20
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).

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

Re: Simplifying Vulkan one subsystem at a time

#23

Post by hyperman1 »

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.

No. I remember a phone app ( Whatsapp?) doggedly supporting every godforsaken phone, even the nokias with the zillion incompatible Java versions. A developer should go where the customers are.

What does help is an industry accepted benchmark, easily ran by everyone. I remember browser css being all over the place, until that whatsitsname benchmark (with the smiley face) demonstrated which emperors had no clothes. Everyone could surf to the test and check how well their favorite browser did. Scores went up quickly, and today, css is in a lot better shape.

Re: Simplifying Vulkan one subsystem at a time

#24

Post by m-schuetz »

jorvi wrote: post #21
reactordev wrote: post #12

Earlier quoted context omitted.

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.

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.

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.

Re: Simplifying Vulkan one subsystem at a time

#25

Post by Octoth0rpe »

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.

> we should more readily abandon GPU vendors

This was so much more practical before the market coalesced to just 3 players. Matrox, it's time for your comeback arc! and maybe a desktop pcie packaging for mali?

Re: Simplifying Vulkan one subsystem at a time

#26

Post by jauntywundrkind »

adithyassekhar wrote: post #22
zamalek wrote: post #20

Earlier quoted context omitted.

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

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.

Re: Simplifying Vulkan one subsystem at a time

#27

Post by horsawlarway »

adithyassekhar wrote: post #22
zamalek wrote: post #20

Earlier quoted context omitted.

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

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

Not joking, Arch. Pick Gnome/KDE/Sway as you please.

Arch is a wonderful daily driver distro for folks who can deal with even a small amount of configuration.

Excellent software availability through AUR, excellent update times (pretty much immediate).

The only downside is there's not a ton of direct commercial software packaged for it by default (ex - most companies they care give a .deb or a .rpm) but that's easily made up for by the rest of AUR.

It's not even particularly hard to install anymore - run `archinstall` https://wiki.archlinux.org/title/Archinstall make some choices, get a decent distro.

Throw in that steam support is pretty great... and it's generally one of the best distros available right now for general use by even a moderate user.

Also fine as a daily driver for kids/spouses as long as there's someone in the house to run pacman every now and then, or help install new stuff.

Re: Simplifying Vulkan one subsystem at a time

#28

Post by jauntywundrkind »

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://news.ycombinator.com/item?id=42209272

Re: Simplifying Vulkan one subsystem at a time

#29

Post by zamalek »

adithyassekhar wrote: post #22
zamalek wrote: post #20

Earlier quoted context omitted.

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

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

If you want something relatively uninteresting: Fedora or Debian (honestly, stable is fine).

If you want something extremely reliable, more modern, but may require some learning to tweak: Silverblue or Kinoite.

Re: Simplifying Vulkan one subsystem at a time

#30

Post by flohofwoe »

jorvi wrote: post #21
reactordev wrote: post #12

Earlier quoted context omitted.

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.

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.

> 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 will be triggered and fixed, especially when most Unity or Unreal game projects will simply select the D3D11 or D3D12 backend since their main target platform on PC is Windows.

Similar problem to when GLQuake was the only popular OpenGL game, as soon as your own code used the GL API in a slightly different way than Quake did all kinds of things broke since those GL drivers only properly implemented and tested the GL subset used by GLQuake, and with the specific function call patterns of GLQuake.

From what I've seen so far, the MESA Vulkan drivers on Linux seem to be in much better shape than the average Windows Vulkan driver. The only explanation I have for this is that there are hardly any Windows games running on top of Vulkan (instead they use D3D11 or D3D12), while running those same D3D11/D3D12 games on Linux via Proton always goes through the Vulkan driver. So on Linux there may be more 'evolutionary pressure' to get high quality Vulkan drivers indirectly via D3D11/D3D12 games that run via Proton.

Post reply on HN