Does this evolution of the Vulkan API get closer to the model explained in https://www.sebastianaaltonen.com/blog/no-graphics-api which we discussed in https://news.ycombinator.com/item?id=46293062 ?
Simplifying Vulkan one subsystem at a time
31–40 of 200 posts
Re: Simplifying Vulkan one subsystem at a time
#32How 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, 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.
Re: Simplifying Vulkan one subsystem at a time
#33At 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...
[flagged]
Re: Simplifying Vulkan one subsystem at a time
#34The 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).
You don't have to run LTS. There is a new release every 6 months.
Re: Simplifying Vulkan one subsystem at a time
#35How 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, 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 descr…
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.
Re: Simplifying Vulkan one subsystem at a time
#36How 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 try my best to push ML things into WebGPU and I think it has a future, but performance is not there yet. I have little experience with Vulkan except toy projects, but WebGPU and Vulkan seem very similar
Re: Simplifying Vulkan one subsystem at a time
#37Earlier quoted context omitted.
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 descr…
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 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.
Re: Simplifying Vulkan one subsystem at a time
#38Does this evolution of the Vulkan API get closer to the model explained in https://www.sebastianaaltonen.com/blog/no-graphics-api which we discussed in https://news.ycombinator.com/item?id=46293062 ?
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.
Re: Simplifying Vulkan one subsystem at a time
#39Does this evolution of the Vulkan API get closer to the model explained in https://www.sebastianaaltonen.com/blog/no-graphics-api which we discussed in https://news.ycombinator.com/item?id=46293062 ?
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) 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").
Re: Simplifying Vulkan one subsystem at a time
#40Earlier 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?
Arch or Endeavour