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

141–150 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#141

Post by sxzygz »

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 at any given instant, we simply queue work for it.

Given all these contrivances, why should not the interface exposed to the user be absolutely simple. It should then be up to vendors to produce hardware (and co-designed compilers) to run our software as fast as possible.

Graphics developers need to develop a narrow-waist abstraction for wide, latency-hiding, SIMD compute. On top of this Vulkan, or OpenGL, or ML inference, or whatever can be done. The memory space should also be fully unified.

This is what needs to be worked on. If you don’t agree, that’s fine, but don’t pretend that you’re not protecting entrenched interests from the likes of Microsoft, Nvidia, Epic Games, Valve and others.

Telling people to just use Unreal engine, or Unity, or even Godot, it just like telling people to just use Python, or Typescript, or Go to get their sequential compute done.

Expose the compute!

Re: Simplifying Vulkan one subsystem at a time

#142

Post by nice_byte »

m-schuetz wrote: post #140
nice_byte wrote: post #137

Earlier quoted context omitted.

> It's explicitly saying you want device memory You are also explicitly saying that you want device memory by specifying DEVICE_LOCAL_BIT. There's no difference. > Likewise, your claim about UMA makes zero sense. Device malloc gets you a pointer or handle to device memory, It makes zero sense to you because we're talking past each other. I am saying that on systems without UMA you _have_ to care where your resources…

> You are also explicitly saying that you want device memory by specifying DEVICE_LOCAL_BIT. There's no difference. There is. One is a simple malloc call, the other uses arguments with numerous combinations of usage flags which all end up doing exactly the same, so why do thy even exist. > You _have_ to be able to allocate both on host and device. cuMemAlloc and cuMemAllocHost, as mentioned before. > Because there's…

> I want the simple approach in addition what exists now, so we can both have our cakes.

The simple approach can be implemented on top of what Vulkan exposes currently.

In fact, it takes only a few lines to wrap that VMA snippet above and you never have to stare at those pesky structs again!

But Vulkan the API can't afford to be "like CUDA" because Vulkan is not a compute API for Nvidia GPUs. It has to balance a lot of things, that's the main reason it's so un-ergonomic (that's not to say there were no bad decisions made. Renderpasses were always a bad idea.)

Re: Simplifying Vulkan one subsystem at a time

#143

Post by m-schuetz »

nice_byte wrote: post #142
m-schuetz wrote: post #140

Earlier quoted context omitted.

> You are also explicitly saying that you want device memory by specifying DEVICE_LOCAL_BIT. There's no difference. There is. One is a simple malloc call, the other uses arguments with numerous combinations of usage flags which all end up doing exactly the same, so why do thy even exist. > You _have_ to be able to allocate both on host and device. cuMemAlloc and cuMemAllocHost, as mentioned before. > Because there's…

> I want the simple approach in addition what exists now, so we can both have our cakes. The simple approach can be implemented on top of what Vulkan exposes currently. In fact, it takes only a few lines to wrap that VMA snippet above and you never have to stare at those pesky structs again! But Vulkan the API can't afford to be "like CUDA" because Vulkan is not a compute API for Nvidia GPUs. It has to balance a lot…

> In fact, it takes only a few lines to wrap that VMA snippet above and you never have to stare at those pesky structs again!

If it were just this issue, perhaps. But there are so many more unnecessary issues that I have no desire to deal with, so I just started software-rasterizing everything in Cuda instead. Which is way easier because Cuda always provides the simple API and makes complexity opt-in.

Re: Simplifying Vulkan one subsystem at a time

#144

Post by MindSpunk »

m-schuetz wrote: post #140
nice_byte wrote: post #137

Earlier quoted context omitted.

> It's explicitly saying you want device memory You are also explicitly saying that you want device memory by specifying DEVICE_LOCAL_BIT. There's no difference. > Likewise, your claim about UMA makes zero sense. Device malloc gets you a pointer or handle to device memory, It makes zero sense to you because we're talking past each other. I am saying that on systems without UMA you _have_ to care where your resources…

> You are also explicitly saying that you want device memory by specifying DEVICE_LOCAL_BIT. There's no difference. There is. One is a simple malloc call, the other uses arguments with numerous combinations of usage flags which all end up doing exactly the same, so why do thy even exist. > You _have_ to be able to allocate both on host and device. cuMemAlloc and cuMemAllocHost, as mentioned before. > Because there's…

What exactly is the difference between these?

cuMemAlloc -> vmaAllocate + VMA_MEMORY_USAGE_GPU_ONLY

cuMemAllocHost -> vmaAllocate + VMA_MEMORY_USAGE_CPU_ONLY

It seems like the functionality is the same, just the memory usage is implicit in cuMemAlloc instead of being typed out? If it's that big of a deal write a wrapper function and be done with it?

Usage flags never come up in CUDA because everything is just a bag-of-bytes buffer. Vulkan needs to deal with render targets and textures too which historically had to be placed in special memory regions, and are still accessed through big blocks of fixed function hardware that are very much still relevant. And each of the ~6 different GPU vendors across 10+ years of generational iterations does this all differently and has different memory architectures and performance cliffs.

It's cumbersome, but can also be wrapped (i.e. VMA). Who cares if the "easy mode" comes in vulkan.h or vma.h, someone's got to implement it anyway. At least if it's in vma.h I can fix issues, unlike if we trusted all the vendors to do it right (they wont).

Re: Simplifying Vulkan one subsystem at a time

#145

Post by simonask »

the8472 wrote: post #113
jsheard wrote: post #92

Earlier quoted context omitted.

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

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 magnitude faster than you can tell it manually how to update even a single pixel.

Not using it is silly when you look at it that way.

Re: Simplifying Vulkan one subsystem at a time

#146

Post by LoganDark »

hinkley wrote: post #94
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…

I’m not watching Rust as closely as I once did, but it seems like buffer ownership is something it should be leaning on more fully. There’s an old concurrency pattern where a producer and consumer tag team on two sets of buffers to speed up throughput. Producer fills a buffer, transfers ownership to the consumer, and is given the previous buffer in return. It is structurally similar to double buffered video, but for…

> There’s an old concurrency pattern where a producer and consumer tag team on two sets of buffers to speed up throughput. Producer fills a buffer, transfers ownership to the consumer, and is given the previous buffer in return.

Isn't this just called a swapchain?

Re: Simplifying Vulkan one subsystem at a time

#147

Post by hutao »

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

This is my point of view as someone who learned WebGPU as a precursor to learning Vulkan, and who is definitely not a graphics programming expert:

My personal experience with WebGPU wasn't the best. One of my dislikes was pipelines, which is something that other people also discuss in this comment thread. Pipeline state objects are awkward to use without an extension like dynamic rendering. You get a combinatorial explosion of pipelines and usually end up storing them in a hash map.

In my opinion, pipelines state objects are a leaky abstraction that exposes the way that GPUs work: namely that some state changes may require some GPUs to recompile the shader, so all of the state should be bundled together. In my opinion, an API for the web should be concerned with abstractions from the point of view of the programmer designing the application: which state logically acts as a single unit, and which state may change frequently?

It seems that many modern APIs have gone with the pipeline abstraction; for example, SDL_GPU also has pipelines. I'm still not sure what the "best practices" are supposed to be for modern graphics programming regarding how to structure your program around pipelines.

I also wish that WebGPU had push constants, so that I do not have to use a bind group for certain data such as transformation matrices.

Because WebGPU is design-by-committee and must support the lowest common denominator hardware, I'm worried whether it will evolve too slowly to reflect whatever the best practices are in "modern" Vulkan. I hope that WebGPU could be a cross-platform API similar to Vulkan, but less verbose. However, it seems to me that by using WebGPU instead of Vulkan, you currently lose out on a lot of features. Since I'm still a beginner, I could have misconceptions that I hope other people will correct.

Re: Simplifying Vulkan one subsystem at a time

#148

Post by nickjj »

cosmic_cheese wrote: post #98
horsawlarway wrote: post #96

Earlier quoted context omitted.

I find this a very reasonable take. I'll add - I think the complexity is somewhat "over-stated" for Arch at this point. There was absolutely a period where just reading the entire install guide (much less actually completing it) was enough to turn a large number of even fairly technical people off the distro. Archinstall removed a lot of that headache. And once it's up, it's generally just fine. I moved both my spous…

YMMV, but the issue I usually run into with Arch is that unless you watch patch notes like a hawk, updates will break random things every so often, which I found quite frustrating. The risk of this increases the longer the system goes without updates due to accumlated missing config file migrations and such. Even as someone who uses the terminal daily it's more involved than I really care for.

> but the issue I usually run into with Arch is that unless you watch patch notes like a hawk,

The good news is you can run `yay -Pwwq` to get the latest Arch news headlines straight in your terminal.

I've wrapped that with running `pacman -Syu` into a little helper script so that I always get to see the news before I run an update.

This is built into my dotfiles by default at https://github.com/nickjj/dotfiles.

Re: Simplifying Vulkan one subsystem at a time

#149

Post by thegrim000 »

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 limiting your code to running on 75% of devices. Or, you wait another 5 years to get into the 90s.

Re: Simplifying Vulkan one subsystem at a time

#150

Post by Dylan16807 »

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…

Sure, use it. But it very much shouldn't be needed, and if there's a bug keeping you from using it your performance outside video games should still be fine. Your average new frame only changes a couple pixels, and a CPU can copy rectangles at full memory speed.
Post reply on HN