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

161–170 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#161

Post by bayindirh »

fiddlerwoaroof wrote: post #121
bayindirh wrote: post #70

Earlier quoted context omitted.

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

I've had a couple outages due to major version upgrades: the worst was the major version update that introduced systemd, but I don't think I've ever irreparably lost a box. The main reason I like nixos now is: 1) nix means I have to install a lot fewer packages globally, which prevents accidentally using the wrong version of a package in a project. 2) I like having a version controlled record of what my systems look…

I prefer to isolate my development environment already in various ways (virtualenv, containers or VM depending on the project) so I don't need that parts of NixOS. My systems are already run on a well-curated set of software. Two decades allowed me to fine tune that aspect pretty well.

While I understand the gravitas of NixOS, that modus operandi just is not for me. I'm happy and fine with my traditional way.

However, as I said, I understand and respect who use NixOS. I just don't share the same perspective and ideas. Hope it never breaks on you.

Re: Simplifying Vulkan one subsystem at a time

#162

Post by exDM69 »

thegrim000 wrote: post #149
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…

Yes, this is the problem. They tout this new latest and greatest extension that fixes and simplifies a lot, yet you go look up the extension on vulkan.gpuinfo.org and see ... currently 0.3% of all devices support it. Which means you can't in any way use it. So you wait 5 years, and now maybe 20% of devices support it. Then you wait another 5 years, and maybe 75% of devices support it. And maybe you can get away with…

> look up the extension on vulkan.gpuinfo.org and see ... currently 0.3% of all devices support it.

Afaik the extension isn't even finalized yet and they are pre-releasing it to gather feedback.

And you can't use gpuinfo for assessing how widely available something is or isn't. The stats contain reports from old drivers too so the numbers you see are no indication of hardware support.

To assess how widely supported something is, you need to look at gpuinfo, sort by date or driver version and cross reference something like steam hardware survey.

Re: Simplifying Vulkan one subsystem at a time

#163

Post by exDM69 »

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)

> or you leave performance on the floor

The dynamic rendering local read feature is for this. You can get tiler gpus working on the happy path without the need for verbose render passes.

But mobile driver support being what it is, it'll take time until it's widespread in consumer devices (which don't get driver updates).

Re: Simplifying Vulkan one subsystem at a time

#164

Post by flohofwoe »

sxzygz wrote: post #141
sxzygz wrote: post #74

Uuugh, graphics. So many smart people expending great energy to look busy while doing nothing particularly profound. Graphics people, here is what you need to do. 1) Figure out a machine abstraction. 2) Figure out an abstraction for how these machines communicate with each other and the cpu on a shared memory bus. 3) Write a binary spec for code for this abstract machine. 4) Compilers target this abstract machine. 5)…

I don’t know which of my detractors to respond to, so I’ll respond here. It should be clear that I’m only interested in compute and not a GPU expert. GPUs, from my understanding, have lost the majority of fixed-function units as they’ve become more programmable. Furthermore, GPUs clearly have a hidden scheduler and this is not fully exposed by vendors. In other words we have no control over what is being run on a GPU…

> GPUs, from my understanding, have lost the majority of fixed-function units as they’ve become more programmable.

That would be nice but doesn't match reality unfortunately, there are even new fixed-fuction units added from time to time (e.g. for raytracing).

Texture sampling units also seem to be critical for performance and probably won't go away for a while.

It should be possible to hide a lot of the fixed-function magic behind high level GPU instructions (e.g. for sampling a texture), but GPU vendors still don't agree about details like how the texture and sampler properties are managed on the GPU (see: https://www.gfxstrand.net/faith/blog/2022/08/descriptors-are...).

E.g. the problem isn't in the software, but the differing hardware designs, and GPU vendors don't seem to like the idea of harmonizing their GPU architectures and they're also not a fan of creating a common ISA as compatibility shim (e.g. how it is common for CPUs). Instead the 3D API, driver and highlevel shader bytecode (e.g. SPIRV) is this common interface, and that's how we landed at the current situation with all its downsides (most of the reasons are probably not even technical, but legal/strategic - patents and stuff).

Re: Simplifying Vulkan one subsystem at a time

#165

Post by happymellon »

akdev1l wrote: post #71
r_lee wrote: post #62

Earlier quoted context omitted.

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.

No Debian is stable as in “it shall not change”. There are times where there are known bugs in Debian which are purposely not fixed but instead documented and worked around. That’s part of the stability promise. The behaviour shall not change which sometimes includes “bug as a feature”

Basically this.

https://xkcd.com/1172/

Re: Simplifying Vulkan one subsystem at a time

#166

Post by imtringued »

simonask wrote: post #145
the8472 wrote: post #113

Earlier quoted context omitted.

Most of the pixels don't change every second though. Compositors do have damage tracking APIs, so you only need to render that which changed. Scrolling can be mostly offset transforms (browsers do that, they'd be unbearably slow otherwise).

That’s not the slow part. The slow part is moving any data at all to the GPU - doesn’t super matter if it’s a megabyte or a kilobyte. And you need it there anyway, because that’s what the display is attached to. Now, the situation is that your display is directly attached to a humongously overpowered beefcake of a coprocessor (the GPU), which is hyper-optimized for calculating pixel stuff, and it can do it orders of…

I'm kinda weirded out by the fact that their renderer takes 3ms on a desktop graphics card that is capable of rendering way more demanding 3D scenes in a video game.

Re: Simplifying Vulkan one subsystem at a time

#167

Post by pjmlp »

reactordev wrote: post #106
flohofwoe wrote: post #103

Earlier quoted context omitted.

280 games over 10 years really isn't impressive (2.5x less than even D3D8 which was an unpopular 'inbetween' D3D version and only relevant for about 2 years). D3D12 (890 games) isn't great either when compared to D3D11 (4.6k) or D3D9 (3.3k), it really demonstrates what a massive failure the modern 3D APIs are for real-world usage :/ I don't think those lists are complete, but they seem to show the right relative amou…

I’m just pointing out that Vulkan is supported on all major modern engines, internal and public. Some also go so far as to do DX12 (fine, it’s a similar feeling API) but what’s really amazing is taking all of those games that run on OpenGL, DirectX, etc and forcing them to run on Vulkan… Proton is amazing and Wine project deserves your support.

What deserves our support is pushing for native Linux games, not helping to keep Windows status quo by making use of Wine and Proton.

It is no different from being happy to use Amiga, Atari, Nintendo, PlayStation, Spectrum, C64, NeoGeo emulators on Linux.

Re: Simplifying Vulkan one subsystem at a time

#168

Post by pjmlp »

m-schuetz wrote: post #77
quantummagic wrote: post #75

Earlier quoted context omitted.

Isn't that what the Zink, ANGLE, or GLOVE projects meant to provide? Allow you to program in OpenGL, which is then automatically translated to Vulkan for you.

I don't see the point of those when I can just directly use OpenGL. Any translation layer typically comes with limitations or issues. Also, I'm not that glued to OpenGL, I do think it's a terrible API, but there just isn't anything better yet. I wanted Vulkan to be something better, but I'm not going to use an API with entirely pointless complexity with zero performance benefits for my use cases.

That is the approach Google is taking, by making Vulkan the only 3D API on Android.

See Android ANGLE on Vulkan roadmap,

https://developer.android.com/games/develop/vulkan/overview#...

Re: Simplifying Vulkan one subsystem at a time

#169

Post by pjmlp »

reactordev wrote: post #130
fc417fc802 wrote: post #127

Earlier quoted context omitted.

> OpenGL is dead for new projects. Says who? Why? It looks long term stable to me so I don't see the issue.

DirectX 9 is long term stable so I don't see the issue... No current gen console supports it. Mac is stuck on OpenGL 4.1 (you can't even compile anything OpenGL on a Mac without hacks). Devices like Android run Vulkan more and more and are sunsetting OpenGLES. No, OpenGL is dead. Vulkan/Metal/NVN/DX12/WebGPU are the current.

Nintendo Switch supports OpenGL, across all its models.

https://www.khronos.org/conformance/adopters/conformant-prod...

https://www.khronos.org/conformance/adopters/conformant-prod...

https://www.khronos.org/conformance/adopters/conformant-prod...

Re: Simplifying Vulkan one subsystem at a time

#170

Post by adornKey »

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…

Currently Debian wants to deprecate GTK2. So even the guys that are interested in stability might start to see problems with Debian. The key problem of Linux is that it doesn't have a stable API to write long living GUI-software for. So far Debian was the way to go. Maybe recommending Debian will become even less popular soon.
Post reply on HN