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

121–130 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#121

Post by fiddlerwoaroof »

bayindirh wrote: post #70
fiddlerwoaroof wrote: post #68

Earlier quoted context omitted.

Over time I evolved to Debian testing for the base system and nix for getting precise versions of tools, which worked fairly well. But, I just converted my last Debian box to nixos

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 like (and I actually like the nix language)

Re: Simplifying Vulkan one subsystem at a time

#122

Post by nice_byte »

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

Earlier quoted context omitted.

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

> No you don't, cuMemAlloc(&ptr, size) will just give you device memory, and cuMemAllocHost will give you pinned host memory.

that's exactly what i said. You have to explicitly allocate one or the other type of memory. I.e. you have to think about what you need this memory _for_. It's literally just usage flags with extra steps.

> Why would UMA be necessary for this?

UMA is necessary if you want to be able to "just allocate some memory without caring about usage flags". Which is something you're not doing with CUDA.

> OpenGL handles this trivially,

OpenGL also doesn't allow you to explicitly manage memory. But you were asking for an explicit malloc. So which one do you want, "just make me a texture" or "just give me a chunk of memory"?

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

Sure, that's what VMA gives you (modulo usage flags, which as we had established you can't get rid of). Excerpt from some code:

``` VmaAllocationCreateInfo vma_alloc_info = { .usage = VMA_MEMORY_USAGE_GPU_ONLY, .requiredFlags = VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT};

VkImage img; VmaAllocation allocn; const VkResult create_alloc_vkerr = vmaCreateImage( vma_allocator, &vk_image_info, // Since i dont care about reslurce aliasing, that's the extent of "memory management" that i do in my rhi. The last time i had to think about different heap types or how to bind memory was approximately never.

Re: Simplifying Vulkan one subsystem at a time

#123

Post by cmovq »

softfalcon wrote: post #84
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 also want what you're describing. It seems like the ideal "data-in-out" pipeline for purely compute based shaders. I've brought it up several times when talking with folks who work down in the chip level for optimizing these operations and all I can say is, there are a lot of unforeseen complications to what we're suggesting. It's not that we can't have a GPU that does these things, it's apparently more of a combin…

This is true, but what the parent comment is getting at is we really just want to be able to address graphics memory the same way it's exposed in CUDA for example. Where you can just have pointers to GPU memory in structures visible to the CPU, without this song and dance with descriptor set bindings.

Re: Simplifying Vulkan one subsystem at a time

#124

Post by p_l »

nicebyte wrote: post #104
Animats wrote: post #101

Not sure if this is an "oh, no" event. So this goes into Vulkan. Then it has to ship with the OS. Then it has to go into intermediate layers such as WGPU. Which will probably have to support both old and new mode. Then it has to go into renderers. Which will probably have to support both old and new mode. Maybe at the top of the renderer you can't tell if you're in old or new mode, but it will probably leak through.…

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

Re: Simplifying Vulkan one subsystem at a time

#125

Post by dyingkneepad »

Octoth0rpe wrote: post #25
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.

> we should more readily abandon GPU vendors This was so much more practical before the market coalesced to just 3 players. Matrox, it's time for your comeback arc! and maybe a desktop pcie packaging for mali?

The market is not just 3 players. These days we have these things called smartphones, and they all include a variety of different graphics cards on them. And even more devices than just those include decently powerful GPUs as well. If you look at the Contributors section of the extension in the post, and look at all the companies involved, you'll have a better idea.

Re: Simplifying Vulkan one subsystem at a time

#126

Post by dyingkneepad »

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

They have done it. The current modern abstraction is called Vulkan, and the binary spec code for this machine is called SPIR-V.

Re: Simplifying Vulkan one subsystem at a time

#127

Post by fc417fc802 »

reactordev wrote: post #80
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.

Those are mostly designed for back porting and not new projects. OpenGL is dead for new projects.

> OpenGL is dead for new projects.

Says who? Why?

It looks long term stable to me so I don't see the issue.

Re: Simplifying Vulkan one subsystem at a time

#128

Post by m-schuetz »

nice_byte wrote: post #122
m-schuetz wrote: post #111

Earlier quoted context omitted.

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

> No you don't, cuMemAlloc(&ptr, size) will just give you device memory, and cuMemAllocHost will give you pinned host memory. that's exactly what i said. You have to explicitly allocate one or the other type of memory. I.e. you have to think about what you need this memory _for_. It's literally just usage flags with extra steps. > Why would UMA be necessary for this? UMA is necessary if you want to be able to "just a…

No, it's not usage flags with extra steps, it's less steps. It's explicitly saying you want device memory without any kind of magical guesswork of what your numerous potential combinations of usage flags may end up giving you. Just one simple device malloc.

Likewise, your claim about UMA makes zero sense. Device malloc gets you a pointer or handle to device memory, UMA has zero relation to that. The result can be unified, but there is no need for it to be.

Yeah, OpenGL does not do malloc. I'm flexible, I don't necessarily need malloc. What I want is a trivial way to allocate device memory, and Vulkan and VMA don't do that. OpenGL is also not the best example since it also uses usage flags in some cases, it's just a little less terrible than Vulkan when it comes to texture memory.

I find it fascinating how you're giving a bad VMA example and passing that of as exemplary. Like, why is there gpu-only and device-local. That vma alloc info as a whole is completely pointless because a theoretical vkMalloc should always give me device memory. I'm not going to allocate host memory for my 3d models.

Re: Simplifying Vulkan one subsystem at a time

#129

Post by pjmlp »

torginus wrote: post #97
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.

Is it possible to support OpenGL on top of Vulkan well? It has been pointed out that Vulkan requires you to completely freeze and compile a graphics pipeline before using it, while OpenGL's state machine is more flexible, and the underlying hardware is somewhat more amenable to these state transitions at runtime, than the Vulkan API would suggest. Don't these compatibility layers run into issues with constant pipelin…

It is no different from running DirectX on Vulkan, DirectX or Vulkan on Metal.

It works, kind of.

Re: Simplifying Vulkan one subsystem at a time

#130

Post by reactordev »

fc417fc802 wrote: post #127
reactordev wrote: post #80

Earlier quoted context omitted.

Those are mostly designed for back porting and not new projects. OpenGL is dead for new projects.

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

Post reply on HN