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

111–120 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#111

Post by m-schuetz »

nicebyte wrote: post #109
m-schuetz wrote: post #105

Earlier quoted context omitted.

Nah, I know about VMA and it's a poor bandaid. I want a single-line malloc with zero care about usage flags and which only produces one single pointer value, because that's all that's needed in pretty much all of my use cases. VMA does not provide that. And Vulkans unnecessary complexity doesn't stop at that issue, there are plenty of follow-up issues that I also have no intention of dealing with. Instead, I'll just…

> I want a single-line malloc with zero care about usage flags and which only produces one single pointer value That's not realistic on non-UMA systems. I doubt you want to go over PCIe every time you sample a texture, so the allocator has to know what you're allocating memory _for_. Even with CUDA you have to do that. And even with unified memory, only the implementation knows exactly how much space is needed for a…

> Even with CUDA you have to do that.

No you don't, cuMemAlloc(&ptr, size) will just give you device memory, and cuMemAllocHost will give you pinned host memory. The usage flags are entirely pointless. Why would UMA be necessary for this? There is a clear separation between device and host memory. And of course you'd use device memory for the texture data. Not sure why you're constructing a case where I'd fetch them from host over PCI, that's absurd.

> only the implementation knows exactly how much space is needed for a texture with a given format and configuration

OpenGL handles this trivially, and there is also no reason for a device malloc to not also work trivially with that. Let me create a texture handle, and give me a function that queries the size that I can feed to malloc. That's it. No heap types, no usage flags. You're making things more complicated than they need to be.

Re: Simplifying Vulkan one subsystem at a time

#112

Post by flohofwoe »

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

Wow, you should get NVIDIA, AMD and Intel on the phone ASAP! Really strange that they didn't come up with such a simple and straightforward idea in the last 3 decades ;)

Re: Simplifying Vulkan one subsystem at a time

#113

Post by the8472 »

jsheard wrote: post #92
ronsor wrote: post #57

Earlier quoted context omitted.

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

Such is life when built-in laptop displays are now pushing a billion pixels per second, rendering anything on the CPU adds up fast. Sublime Text spent over a decade tuning their CPU renderer and it still didn't cut it at high resolutions. https://www.sublimetext.com/blog/articles/hardware-accelerat...

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

Re: Simplifying Vulkan one subsystem at a time

#114

Post by fc417fc802 »

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 use of various fixed function hardware that you currently benefit from.

Re: Simplifying Vulkan one subsystem at a time

#115

Post by flohofwoe »

cmovq wrote: post #69
flohofwoe wrote: post #48

Earlier quoted context omitted.

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

That abstraction exists in D3D11 and to a lesser extent in Metal via smaller state-group-objects (for instance D3D11 splits the rende state into immutable objects for rasterizer-state, depth-stencil-state, blend-state and (vertex-)input-layout-state (not even needed anymore with vertex pulling).

Even if those state group objects don't match the underlying hardware directly they still reign in the combinatorial explosion dramatically and are more robust than the GL-style state soup.

AFAIK the main problem is state which needs to be compiled into the shader on some GPUs while other GPUs only have fixed-function hardware for the same state (for instance blend state).

Re: Simplifying Vulkan one subsystem at a time

#116

Post by fc417fc802 »

6SixTy wrote: post #55
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).

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.

> Flatpak ships as it's own system managing Mesa versions.

Mixing and matching the kernel and userspace mesa components is subject to limitations. However it will transparently fall back to software rendering so you might not notice if you aren't doing anything intensive.

Related, being a container flatpak has no choice but to ship the mesa userspace component. If it didn't nothing would work.

Re: Simplifying Vulkan one subsystem at a time

#117

Post by flohofwoe »

nicebyte wrote: post #99
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)…

some of this is what's khronos standards are theoretically supposed to achieve. surprise, it's very difficult to do across many hw vendors and classes of devices. it's not a coincidence that metal is much easier to program for. maybe consider joining khronos since you apparently know exactly how to achieve this very simple goal...

> it's not a coincidence that metal is much easier to program for

Tbf, Metal also works on non-Apple GPUs and with only minimal additional hints to manage resources in non-unified memory.

Re: Simplifying Vulkan one subsystem at a time

#118

Post by jauntywundrkind »

gspr wrote: post #107
jauntywundrkind wrote: post #26

Earlier quoted context omitted.

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.

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.

Re: Simplifying Vulkan one subsystem at a time

#119

Post by jauntywundrkind »

r_lee wrote: post #63
jauntywundrkind wrote: post #26

Earlier quoted context omitted.

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

I run sid (debian's unstable branch) on all my systems, it's great! With experimental pinned on at low priority! It's great, I love it!

I'm not quite bold enough to recommend it to people but if anyone asks I would definitely say yes to running sid. Apt-pin for testing at low priority is good to have, just because sometimes there's lag when one library updates for everyone using it to update, and you can get unsatisfiable dependencies.

Re: Simplifying Vulkan one subsystem at a time

#120

Post by fc417fc802 »

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…

You're allowed to throw debian testing or arch in a chroot. The only thing that doesn't work well for is gaming since it's possible for the mesa version to diverge too far.
Post reply on HN