Re:Vulkan Memory Allocator
by flohofwoe on Wednesday July 21, 2021 @10:26AM
(#27906706)
But the thing is that Vulkan isn't the lowest possible hardware interface, it's still built on top of a virtual GPU abstraction which matches some GPUs better than others. There's a ton of compromises to accomodate mobile GPUs for instance. The only realistic way to achieve the goal of an actually low-level API is to have one API per major GPU architecture, and to create new APIs when new GPU architectures emerge. Attempts to abstract over radically different GPU architectures will never result in an actually explicit low-level API.
[ Parent
| on HN ]
Ok yeah that's technically true, but there's always going to be a balance point. You can't expect graphics programmers to write a separate renderer for each possible hardware target. That kind of works in the console space, but in the PC space you have to account for a wide variety of hardware.
There's always going to be a balance point, and Vulkan's priority is much more about getting as low-level as possible within the constraints than it is about being approachable for developers.
> it's still built on top of a virtual GPU abstraction which matches some GPUs better than others.
Doesn't khronos contain people from a bunch of different corps (amd, nvidia, intel, qualcom) for this exact reason.
Yeah, but that doesn't seem to have helped much to keep the Vulkan API small and tidy, instead there are dozens (or maybe hundreds by now?) of vendor-specific extensions.
I think this is vastly overstated. I've done quite a bit of work for Vulkan, and have done just fine without reaching for extensions.
And how else do you propose accessing hardware features which are vendor specific?