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

51–60 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#51

Post by horsawlarway »

direwolf20 wrote: post #42
zamalek wrote: post #29

Earlier quoted context omitted.

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?

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 other large project delivering new features relatively quickly)

- Hardware support (modern linux kernels)

I'd recommend it immediately as a replacement for Ubuntu as a server, but I won't run it for daily drivers.

Again - Arch (or it's derivatives) are basically the best you can get in that space.

Re: Simplifying Vulkan one subsystem at a time

#52

Post by pjmlp »

tadfisher wrote: post #44
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.

I did not do such claim.

WebGPU on Android runs on top of Vulkan.

If you knew about 3D programming on Android, you would know that there are ongoing efforts to have only Vulkan, with OpenGL ES on top.

However Java and Kotlin devs refuse to bother with the NDK for Vulkan, and keep reaching for OpenGL ES instead.

Please refer to Google talks on Vulkanised conferences.

Re: Simplifying Vulkan one subsystem at a time

#53

Post by m-schuetz »

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…

> 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

This is where I think Vulkan and WebGPU are chasing the wrong goal: To make draw calls faster. What's even faster, however, is making fewer draw calls and that's something graphics devs can easily do when you provide them with tools like multi-draw. Preferably multi-draw that allows multiple different buffers. Doing so will naturally reduce costly state changes with little effort.

Re: Simplifying Vulkan one subsystem at a time

#54

Post by pjmlp »

kllrnohj wrote: post #33
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...

[flagged]

Thanks for showing the audience the lack of experience with Vulkan drivers on Android.

Re: Simplifying Vulkan one subsystem at a time

#55

Post by 6SixTy »

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

My understanding with Mesa is that it has very few dependencies and is ABI stable, so freezing Mesa updates is counterproductive. I'm not sure about Snaps, but Flatpak ships as it's own system managing Mesa versions.

Re: Simplifying Vulkan one subsystem at a time

#56

Post by horsawlarway »

esseph wrote: post #46
BadBadJellyBean wrote: post #34

Earlier quoted context omitted.

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)

I have a lot of respect for Canonical for driving a distro that was very "noob friendly" in an ecosystem where that's genuinely hard.

But I mostly agree with you. Once you get out of that phase, I don't really see much value in Ubuntu. I'd pick pretty much anything else for everything I do these days. Debian/Fedora/Alpine on the server. Arch on the desktop.

Re: Simplifying Vulkan one subsystem at a time

#57

Post by ronsor »

afandian wrote: post #19
m-schuetz wrote: post #18

Earlier quoted context omitted.

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.

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.

Re: Simplifying Vulkan one subsystem at a time

#58

Post by flohofwoe »

pjmlp wrote: post #52
tadfisher wrote: post #44

Earlier quoted context omitted.

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.

I did not do such claim. WebGPU on Android runs on top of Vulkan. If you knew about 3D programming on Android, you would know that there are ongoing efforts to have only Vulkan, with OpenGL ES on top. However Java and Kotlin devs refuse to bother with the NDK for Vulkan, and keep reaching for OpenGL ES instead. Please refer to Google talks on Vulkanised conferences.

> ...efforts to have only Vulkan, with OpenGL ES on top...

Ok this made me laugh given that Vulkan support on Android is so bad that WebGPU needs a fallback mode to GLES ;)

https://github.com/gpuweb/gpuweb/issues/4266

Re: Simplifying Vulkan one subsystem at a time

#59

Post by pjmlp »

flohofwoe wrote: post #58
pjmlp wrote: post #52

Earlier quoted context omitted.

I did not do such claim. WebGPU on Android runs on top of Vulkan. If you knew about 3D programming on Android, you would know that there are ongoing efforts to have only Vulkan, with OpenGL ES on top. However Java and Kotlin devs refuse to bother with the NDK for Vulkan, and keep reaching for OpenGL ES instead. Please refer to Google talks on Vulkanised conferences.

> ...efforts to have only Vulkan, with OpenGL ES on top... Ok this made me laugh given that Vulkan support on Android is so bad that WebGPU needs a fallback mode to GLES ;) https://github.com/gpuweb/gpuweb/issues/4266

Agreed, which is Google's motivation for doing that.

The argument being that if Android only does Vulkan, that OEMs will be forced to care about their drivers.

There are talks done by Google on this, either Vulkanised, Google IO, or GDC, can't remember now the exact one.

Re: Simplifying Vulkan one subsystem at a time

#60

Post by aeldidi »

hyperman1 wrote: post #23
m-schuetz wrote: post #18

Earlier quoted context omitted.

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

The Acid2 test is the benchmark you’re thinking of, for anyone not aware: acid2.acidtests.org
Post reply on HN