Vulkan Memory Allocator

Re:Vulkan Memory Allocator by flohofwoe on Wednesday July 21, 2021 @10:52AM (#27907102)

I think the counter-intuitive "hindsight-is-20/20" fact is that a higher level, more abstract API provides more wiggle room for GPU vendors to implement optimizations for their specific GPU architecture. "Abstract API" doesn't mean it has to be mess like what OpenGL became after 1.x, but one problem is that many people think that Vulkan was the only possible alternative future to OpenGL, while ignoring APIs like D3D11 and Metal which would have been a better starting point for an OpenGL successor.

[ Parent | on HN ]

Re:Vulkan Memory Allocator by skohan on Wednesday July 21, 2021 @11:19AM (#27907489)

Idk as an "intermediate" graphics programmer, the explicitness and lack of abstraction in Vulkan is one of the killer features for me. "Wiggle room" in higher-level API's like OpenGL is one of the things that made them impossible to deliver consistent results with. With Vulkan there's more typing, but once you get something working it's going to work the same pretty much everywhere.

I kind of see it as a non-issue. It seems like Vulkan's target audience was specifically elite developers who wanted the most control possible, and based on the results which have been achieved in products like Doom 2016/Eternal it seems like it's working for them.

I suspect WebGPU will be the OpenGL successor for everyone working with graphics who isn't at an AAA game studio.

[ Parent | on HN ]

Re:Vulkan Memory Allocator by flohofwoe on Wednesday July 21, 2021 @12:33PM (#27908440)

As I wrote above, OpenGL is an exeptionally bad counter example to Vulkan because it's just a massive soup of knobs and dials. D3D11 and Metal had this specific problem fixed already, and should have been used as base for an OpenGL successor instead of going all radical with Mantle.

Vulkan is basically a GPU-programming API with some support for triangle rendering, great for compute workloads, not so great for rendering triangles. At the very least, Khronos should provide additional layers on top of Vulkan to simplify traditional rendering tasks, basically providing one or more optional API layers that are closer to Metal and D3D11.

[ Parent | on HN ]

Re:Vulkan Memory Allocator by skohan on Wednesday July 21, 2021 @12:54PM (#27908777)

I would recommend watching some of the talks from around the time Vulkan was announced. The API was released very much in response to developer demand to just give them access to the GPU in an unopinionated way, and largely it has delivered on that promise.

[ Parent | on HN ]

Re:Vulkan Memory Allocator by flohofwoe on Wednesday July 21, 2021 @01:15PM (#27909105)

Yeah I was around at the time. As I remember it, the "developer demand" was a very small but very vocal cabal of AAA game rendering engineers :)

I think the general idea was the right one, the execution of that idea was the problem (e.g. Metal is the successful execution of the same idea).

[ Parent | on HN ]

Re:Vulkan Memory Allocator by shmerl on Wednesday July 21, 2021 @06:52PM (#27913176)

Metal gives no choice for the lower level. Something higher level built on Vulkan with ability still to use the lower level for those who need would be the successful execution. Metal isn't that, besides being Apple only anyway.

I.e. I'd agree with your idea if Metal was actually built by Apple on top of Vulkan as a convenience abstraction and you could use Vulkan there directly too.

[ Parent | on HN ]

Re:Vulkan Memory Allocator by flohofwoe on Thursday July 22, 2021 @03:28AM (#27916387)

The first Metal version didn't provide much low-level access, but the later Metal versions gradually added more low-level, more explicit features. The key point is that those features can be ignored if the higher level and more convenient features are good enough.

[ Parent | on HN ]

Re:Vulkan Memory Allocator by skohan on Thursday July 22, 2021 @07:33AM (#27917690)

But I think the parent comment's point is just that if you start with low-level, you can always build on top of it, but the other way around you have to wait for the API vendor to give you the low level access you need.

I hear that you are saying Metal does a better job of being a convenient graphics API than Vulkan. I am just having trouble parsing why this would be an objective problem with Vulkan, rather than you just not being the target audience of this API.

[ Parent | on HN ]

Re:Vulkan Memory Allocator by HelloNurse on Wednesday July 21, 2021 @12:15PM (#27908189)

"Wiggle room" means, for example, that OpenGL drivers might look at the name of your executable to apply different hacks and profiles. It means that you write perfect code, and then who knows what will happen. Thanks, but no thanks.

[ Parent | on HN ]

Re:Vulkan Memory Allocator by flohofwoe on Wednesday July 21, 2021 @12:38PM (#27908506)

Not what meant, besides, if you read NVIDIA and AMD driver release notes carefully, you will find that these also contain game-specific fixes in the Vulkan drivers. It's just rarer because there are not many games using Vulkan.

[ Parent | on HN ]

Re:Vulkan Memory Allocator by pjmlp on Wednesday July 21, 2021 @10:56AM (#27907158)

If you look at Khronos slideware that is kind of the official message, naturally that is what those people end up thinking, specially if they are newbies looking into learning portable 3D APIs.

[ Parent | on HN ]