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

61–70 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#61

Post by MereInterest »

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…

> There are always weird systems with old drivers (looking at Ubuntu 22 LTS)

While I agree with your general point, RHEL stands out way, way more to me. Ubuntu 22.04 and RHEL 9 were both released in 2022. Where Ubuntu 22.04 has general support until mid-2027 and security support until mid-2032, RHEL 9 has "production" support through mid-2032 and extended support until mid-2034.

Wikipedia sources for ubuntu[0] and RHEL [1]:

[0] https://en.wikipedia.org/wiki/Ubuntu#Releases

[1] https://upload.wikimedia.org/wikipedia/en/timeline/fcppf7prx...

Re: Simplifying Vulkan one subsystem at a time

#62

Post by r_lee »

horsawlarway wrote: post #51
direwolf20 wrote: post #42

Earlier quoted context omitted.

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?

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…

Debian has multiple editions, if you want Arch, go for sid/testing.

Stable is stable as in "must not be broken at all costs" kind of stable.

basically everything works just fine. there's occasionally a rare crash or gnome reset where you need to login again, but other than that not many problems.

Re: Simplifying Vulkan one subsystem at a time

#63

Post by r_lee »

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.

You can go for sid too :)

Re: Simplifying Vulkan one subsystem at a time

#64

Post by ianlevesque »

ronsor wrote: post #57
afandian wrote: post #19

Earlier quoted context omitted.

I had a relatively recent graphics card (5 years old perhaps?). I don't care about 3D or games, or whatever. So I was sad not to be able to run a text editor (let's be honest, Zed is nice but it's just displaying text). And somehow the non-accelerated version is eating 24 cores. Just for text. https://github.com/zed-industries/zed/discussions/23623 I ended up buying a new graphics card in the end. I just wish everyon…

The fact that we need advanced GPU acceleration for a text editor is concerning.

Text editor developers get bored too!

Re: Simplifying Vulkan one subsystem at a time

#65

Post by fsloth »

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

" It is now an enterprise OS"

You really want enterprise standards support for your graphics API.

Bleeding edge ...is not nice in graphics. Especially the more complex the systems get, so do the edge cases.

I mean in general. If you are writing a high end game engine don't listen to me, you know better. But if you are a mid-tier graphics wonk like myself 20 year old concepts are usually quite pareto-optimal for _lots_ of stuff and should be robustly covered by most apis.

If I could give one advice for myself 20 years ago.

For anything practical - focus on the platform native graphics API. Windows - DirectX. Mac - OpenGL (20 years ago! Predates metal!. Today ofc would be metal).

I don't think that advice would be much different today (apart from Metal) IF you don't know what to do and just want to start on doing graphics. For senior peeps who know the field do whatever rights for you of course.

Linux - good luck. Find the API that has best support for your card & driver combo - meaning likely the most stabilized with most users.

Re: Simplifying Vulkan one subsystem at a time

#67

Post by pjmlp »

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.

Re: Simplifying Vulkan one subsystem at a time

#68

Post by fiddlerwoaroof »

horsawlarway wrote: post #51
direwolf20 wrote: post #42

Earlier quoted context omitted.

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?

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…

Over time I evolved to Debian testing for the base system and nix for getting precise versions of tools, which worked fairly well. But, I just converted my last Debian box to nixos

Re: Simplifying Vulkan one subsystem at a time

#69

Post by cmovq »

flohofwoe wrote: post #48
m-schuetz wrote: post #37

Earlier quoted context omitted.

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…

There should be a better abstraction to solve the GL state leakage problem than PSOs. We end up with a combinatory explosion of PSOs when some states they abstract are essentially toggling some bits in a GPU register in no way coupled with the rest of the pipeline state.

Re: Simplifying Vulkan one subsystem at a time

#70

Post by bayindirh »

fiddlerwoaroof wrote: post #68
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…

Over time I evolved to Debian testing for the base system and nix for getting precise versions of tools, which worked fairly well. But, I just converted my last Debian box to nixos

I'm using Debian testing in my daily driving desktop(s) for the last, checks notes, 20 years now?

Servers and headless boxes use stable and all machines are updated regularly. Most importantly, stable to stable (i.e. 12 to 13) upgrades takes around 5 minutes incl. final reboot.

I reinstalled Debian once. I had to migrate my system to 64 bit, and there was no clear way to move from 32 to 64 bit at that time. Well, once in 20 years is not bad, if you ask me.

Post reply on HN