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

71–80 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#71

Post by akdev1l »

r_lee wrote: post #62
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…

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”

Re: Simplifying Vulkan one subsystem at a time

#72

Post by reactordev »

jorvi wrote: post #21
reactordev wrote: post #12

Earlier quoted context omitted.

Vulkan is by far the most powerful and the most pain in the ass API I've ever worked with. I agree on every point you just made.

Isn't the idea that 99% of people use a toolkit atop of Vulkan? Like, these days game devs just use Unreal Engine, which abstracts away having to work with the PS5 / PS4, DirectX 12, and Vulkan APIs. I imagine unless it's either for A. edification or B. very bespoke purpose code, you're not touching Vulkan.

No.

There are literally dozens of in-house engines that run on Vulkan. Not everything is Unreal or Unity.

Re: Simplifying Vulkan one subsystem at a time

#73

Post by reactordev »

flohofwoe wrote: post #30
jorvi wrote: post #21

Earlier quoted context omitted.

Isn't the idea that 99% of people use a toolkit atop of Vulkan? Like, these days game devs just use Unreal Engine, which abstracts away having to work with the PS5 / PS4, DirectX 12, and Vulkan APIs. I imagine unless it's either for A. edification or B. very bespoke purpose code, you're not touching Vulkan.

> Isn't the idea that 99% of people use a toolkit atop of Vulkan? This idea creates a serious chicken-egg-problem. Two or three popular engine code bases sitting on top of Vulkan isn't enough 'critical mass' to get robust and high performance Vulkan drivers. When there's so little diversity in the code hammering on the Vulkan API it's unlikely that all the little bugs and performance problems lurking in the drivers w…

>”hardly any Windows games running on top of Vulkan”

I run all my windows games on Vulkan.

https://www.pcgamingwiki.com/wiki/List_of_Vulkan_games

Re: Simplifying Vulkan one subsystem at a time

#74

Post by sxzygz »

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) Programs submit code to driver for AoT compilation, and cache results.

6) Driver has some linker and dynamic module loading/unloading capability.

7) Signal the driver to start that code.

AMD64, ARM, and RISC-V are all basically differing binary specs for a C-machine+MMU+MMIO compute abstraction.

Figure out your machine abstraction and let us normies write code that’s accelerated without having to throw the baby out with the bathwater ever few years.

Oh yes, give us timing information so we can adapt workload as necessary to achieve soft real-time scheduling on hardware with differing performance.

Re: Simplifying Vulkan one subsystem at a time

#75

Post by quantummagic »

m-schuetz wrote: post #24
jorvi wrote: post #21

Earlier quoted context omitted.

Isn't the idea that 99% of people use a toolkit atop of Vulkan? Like, these days game devs just use Unreal Engine, which abstracts away having to work with the PS5 / PS4, DirectX 12, and Vulkan APIs. I imagine unless it's either for A. edification or B. very bespoke purpose code, you're not touching Vulkan.

Many people need something in-between heavy frameworks and engines or oppinionated wrappers with questionable support on top of Vulkan; and Vulkan itself. OpenGL served that purpose perfectly, but it's unfortunately abandoned.

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.

Re: Simplifying Vulkan one subsystem at a time

#76

Post by [deleted] »

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.

[deleted]

Re: Simplifying Vulkan one subsystem at a time

#77

Post by m-schuetz »

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

Earlier quoted context omitted.

Many people need something in-between heavy frameworks and engines or oppinionated wrappers with questionable support on top of Vulkan; and Vulkan itself. OpenGL served that purpose perfectly, but it's unfortunately abandoned.

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.

Re: Simplifying Vulkan one subsystem at a time

#78

Post by bwat49 »

BadBadJellyBean wrote: post #34
zamalek wrote: post #20

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

You don't have to run LTS. There is a new release every 6 months.

not to mention the OP mentioned 22 LTS which isn't even the most current LTS

Re: Simplifying Vulkan one subsystem at a time

#79

Post by jorvi »

flohofwoe wrote: post #30
jorvi wrote: post #21

Earlier quoted context omitted.

Isn't the idea that 99% of people use a toolkit atop of Vulkan? Like, these days game devs just use Unreal Engine, which abstracts away having to work with the PS5 / PS4, DirectX 12, and Vulkan APIs. I imagine unless it's either for A. edification or B. very bespoke purpose code, you're not touching Vulkan.

> Isn't the idea that 99% of people use a toolkit atop of Vulkan? This idea creates a serious chicken-egg-problem. Two or three popular engine code bases sitting on top of Vulkan isn't enough 'critical mass' to get robust and high performance Vulkan drivers. When there's so little diversity in the code hammering on the Vulkan API it's unlikely that all the little bugs and performance problems lurking in the drivers w…

You might be unaware of this, but Vulkan Video Decode is slowly but surely replacing the disparate bespoke video decode acceleration on almost all platforms.

Vulkan is mature. It has been used in production since 2013 (!) in the form of Mantle. I have no idea why all the Vulkan doomsayers here think it still needs a half-to-whole decade to be 'useful'.

Re: Simplifying Vulkan one subsystem at a time

#80

Post by reactordev »

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

Earlier quoted context omitted.

Many people need something in-between heavy frameworks and engines or oppinionated wrappers with questionable support on top of Vulkan; and Vulkan itself. OpenGL served that purpose perfectly, but it's unfortunately abandoned.

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.

Those are mostly designed for back porting and not new projects. OpenGL is dead for new projects.
Post reply on HN