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

41–50 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#41

Post by tonis2 »

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.

Re: Simplifying Vulkan one subsystem at a time

#42

Post by direwolf20 »

zamalek wrote: post #29
adithyassekhar wrote: post #22

Earlier quoted context omitted.

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.

Debian updates even less frequently than Ubuntu and stays with years old versions of packages. If you're looking for fresh, Debian is not it. Maybe Arch?

Re: Simplifying Vulkan one subsystem at a time

#43

Post by [deleted] »

BadBadJellyBean wrote: post #34
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).

You don't have to run LTS. There is a new release every 6 months.

[deleted]

Re: Simplifying Vulkan one subsystem at a time

#44

Post by tadfisher »

pjmlp wrote: post #10

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

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.

Re: Simplifying Vulkan one subsystem at a time

#45

Post by jsheard »

tonis2 wrote: post #41

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…

Relevant: Descriptors are Hard from XDC 2025 - 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.

Re: Simplifying Vulkan one subsystem at a time

#46

Post by esseph »

BadBadJellyBean wrote: post #34
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).

You don't have to run LTS. There is a new release every 6 months.

I've been running Linux for a very long time.

Ubuntu has never ever been the most stable or useful distro. What it did have was apt and more up to date stuff than debian.

I would never willingly choose Ubuntu if allowed other options (Fedora, Debian, maybe CoreOS, etc)

Re: Simplifying Vulkan one subsystem at a time

#47

Post by flohofwoe »

jauntywundrkind wrote: post #28

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

I think in the end it all depends on Android. Average Vulkan driver quality on Android doesn't seem to be great in the first place, getting uptodate Vulkan API support, and in high quality and high enough performance for a modernized WebGPU version to build on might be too much to ask of the Android ecosystem for the next one or two decades.

Re: Simplifying Vulkan one subsystem at a time

#48

Post by flohofwoe »

m-schuetz wrote: post #37
kllrnohj wrote: post #35

Earlier quoted context omitted.

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…

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

> WebGL worked perfectly fine without them

Except it didn't. In the GL programming model it's trivial to accidentially leak the wrong granular render state into the next draw call, unless you always reconfigure all states anyway (and in that case PSOs are strictly better, they just include too much state).

The basic idea of immutable state group objects is a good one, Vulkan 1.0 and D3D12 just went too far (while the state group granularity of D3D11 and Metal is just about right).

> Similarly, WebGPU could have done without that static binding mess.

This I agree with, pre-baked BindGroup objects were just a terrible idea right from the start, and AFAIK they are not even strictly necessary when targeting Vulkan 1.0.

Re: Simplifying Vulkan one subsystem at a time

#49

Post by fulafel »

BadBadJellyBean wrote: post #34
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).

You don't have to run LTS. There is a new release every 6 months.

Especially a 4 year old LTS. But I guess the point was that you will run into some users that do when you ship to the general audience.

You run into the same problem on other platforms too of course (eg Android)

Re: Simplifying Vulkan one subsystem at a time

#50

Post by Cloudef »

jauntywundrkind wrote: post #28

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

WebGPU is kinda meh. It's when you need to do do something on browser that you can't with WebGL. GLES is the compatibility king and runs pretty much everywhere, if not natively then through a compatibility layer like ANGLE. I'm sad that WebGPU killed WebGL 3 which was supposed to add compute shaders. Maybe WebGPU would've been more interesting if it wasn't made to replace WebGL but instead be a non-compatibility API targetting modern rendering and actually supporting Spir-V.
Post reply on HN