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

151–160 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#151

Post by superkuh »

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

And this is a prime example of development-centric thinking prioritizing developer comfort over the capabilities and usability of the actual software. Rather than targeting stable older feature sets it's always targeting the bleeding edge and then being confused that this doesn't work on machines that aren't their own and then blaming everyone else for their decision. 4 years is not a long time (LTS). 4 years is the minimum that software should be able to live.

Re: Simplifying Vulkan one subsystem at a time

#152

Post by socalgal2 »

pjmlp wrote: post #67
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

As always, the only two positive things about WebGL and WebGPU, are being available on browsers, and having been designed for managed languages. They lag behind modern hardware, and after almost 15 years, there are zero developer tools to debug from browser vendors, other than the oldie SpectorJS that hardly counts.

This is kind of ridiculous take

You can use wgpu or dawn in a native app and use native tools for GPU debugging if that's what you want

You can then take that and also run it in the browser, and, you can debug the browser in the same tools. Google it for instructions

The positive things about WebGPU is it's actually portable, unlike Vulkan. And, it's easy to use, unlike Vulkan.

Re: Simplifying Vulkan one subsystem at a time

#153

Post by bsder »

fc417fc802 wrote: post #114
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…

If you got what you're asking for you'd presumably lose access to any fixed function hardware. RE your example, knowing the data format permits automagic hardware accelerated translations between image formats. You're free to do what you're asking after by simply performing all operations manually in a compute shader. You can manually clip, transform, rasterize, and even sample textures. But you'll lose the implicit…

> If you got what you're asking for you'd presumably lose access to any fixed function hardware.

Are there any fixed functions left that aren't just being implemented by the general compute shader hardware?

I guess the ray tracing stuff would qualify, but that isn't what people are complaining about here.

Re: Simplifying Vulkan one subsystem at a time

#154

Post by Animats »

p_l wrote: post #124
nicebyte wrote: post #104

Earlier quoted context omitted.

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

And apparently if you do mobile you stay away from big chunk of dynamic rendering and use Vulkan 1.0 style renderpasses... or you leave performance on the floor (based on guidelines from various mobile GPU vendors)

Vulkan on mobile and web runs several years behind Vulkan on desktop. This is a problem for portable toolkits such as WGPU.

Re: Simplifying Vulkan one subsystem at a time

#155

Post by Hazematman »

cosmic_cheese wrote: post #85
horsawlarway wrote: post #51

Earlier quoted context omitted.

Yeah, the folks in here recommending Debian as a solution to this problem are insane. I love Debian, it's a great distro. It's NOT the distro I'd pick to drive things like my laptop or personal development machine. At least not if you have even a passing interest in: - Using team communication apps (slack/teams/discord) - Using software built for windows (Wine/Proton) - Gaming (of any form) - Wayland support (or any…

I think Debian Stable, Ubuntu LTS, and derivatives thereof are particularly poor fits for general consumers who are more likely to try to run the OS on a random machine they picked up from Best Buy that’s probably built with hardware that kernels any older than what ships in Fedora are unlikely to support. The stable/testing/etc distinction doesn't really help, either, because it's an alien concept to those outside o…

I agree that they are a poor fit for a random user especially for debian install being not as intuitive but for supporting hardware I disagree.

I decided to try debian stable on my brand new gaming PC and it worked fine out of the box. Combine with steam flatpak for gaming and I have less issues than my friends who game on Arch.

I agree though that Fedora is probably a good general recommendation.

Re: Simplifying Vulkan one subsystem at a time

#156

Post by shmerl »

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…

Some just ignore it and require using recent Vulkan (see for example dxvk and etc.). Do that. Ubuntu LTS isn't something you should be using for graphics dependent desktop scenarios anyway. Limiting features based on that is a bad idea.

Re: Simplifying Vulkan one subsystem at a time

#157

Post by gspr »

jauntywundrkind wrote: post #118
gspr wrote: post #107

Earlier quoted context omitted.

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

It's rare but every now and then testing has an unsatisfiable dependency. It's usually resolved within a day or so. But I keep a lower distro around basically to insure I have a fallback, so I'm not blocked now. The next update should likely get me back to testing.

The conventional way to resolve temporarily unsatisfiable dependencies in Testing is to include Unstable at a lower priority, since that's where packages migrate to Testing from. Stable is a distinctly different distribution, and you're far more likely to see e.g. library ABIs from there incompatible with Testing.

Re: Simplifying Vulkan one subsystem at a time

#158

Post by pjmlp »

socalgal2 wrote: post #152
pjmlp wrote: post #67

Earlier quoted context omitted.

As always, the only two positive things about WebGL and WebGPU, are being available on browsers, and having been designed for managed languages. They lag behind modern hardware, and after almost 15 years, there are zero developer tools to debug from browser vendors, other than the oldie SpectorJS that hardly counts.

This is kind of ridiculous take You can use wgpu or dawn in a native app and use native tools for GPU debugging if that's what you want You can then take that and also run it in the browser, and, you can debug the browser in the same tools. Google it for instructions The positive things about WebGPU is it's actually portable, unlike Vulkan. And, it's easy to use, unlike Vulkan.

WebGPU is JavaScript + WebGPU, it has nothing to do with wgpu Rust extensions for native coding, other than sharing a similar API surface.

The very fact that you are suggesting this as workaround proves how bad the tools are.

Re: Simplifying Vulkan one subsystem at a time

#159

Post by m-schuetz »

MindSpunk wrote: post #144
m-schuetz wrote: post #140

Earlier quoted context omitted.

> You are also explicitly saying that you want device memory by specifying DEVICE_LOCAL_BIT. There's no difference. There is. One is a simple malloc call, the other uses arguments with numerous combinations of usage flags which all end up doing exactly the same, so why do thy even exist. > You _have_ to be able to allocate both on host and device. cuMemAlloc and cuMemAllocHost, as mentioned before. > Because there's…

What exactly is the difference between these? cuMemAlloc -> vmaAllocate + VMA_MEMORY_USAGE_GPU_ONLY cuMemAllocHost -> vmaAllocate + VMA_MEMORY_USAGE_CPU_ONLY It seems like the functionality is the same, just the memory usage is implicit in cuMemAlloc instead of being typed out? If it's that big of a deal write a wrapper function and be done with it? Usage flags never come up in CUDA because everything is just a bag-o…

> and are still accessed through big blocks of fixed function hardware that are very much still relevant

But is it relevant for malloc? Everthing is put into the same physical device memory, so what difference would the usage flag make? Specialized texture fetching and caching hardware would come into play anyway when you start fetching texels via samplers.

> It seems like the functionality is the same, just the memory usage is implicit in cuMemAlloc instead of being typed out? If it's that big of a deal write a wrapper function and be done with it?

The main reason I did not even give VMA a chance is the github example that does in 7 lines what Cuda would do in 2. You now say it's not too bad, but that's not reflected in the very first VMA examples.

Re: Simplifying Vulkan one subsystem at a time

#160

Post by tormeh »

pixelpoet wrote: post #8

I would like to / am "supposed to" use Vulkan but it's a massive pain coming from OpenCL, with all kinds of issues that need safe handling which simply don't come from OpenCL workloads. Everyone keeps telling me OpenCL is deprecated (which is true, although it's also true that it continues to work superbly in 2026) but there isn't a good / official OpenCL to Vulkan wrapper out there to justify it for what I do.

I think there's Rusticl for this, although it may not be ready yet.
Post reply on HN