Extension spaghetti for starters, https://vulkan.gpuinfo.org/listextensions.php

Followed by Khronos refusal that it isn't part of their job to define an SDK, so each newbie has to go through the ritual of passage to learn how to get OS abstraction libraries to show up a 3D accelerated window, math library, font handling library, texture and image loading library, shader compiling infrastructure, scene graph to handle meshes,....

Now there is LunarG SDK, which still only offers a subset of these kind of features.

If it wasn't for NVidia's early C++ efforts, Vulkan would still be C only.

Also Vulkan only exists because AMD was so kind to contribute Mantle as starting ground, otherwise Khronos would most likely still be arguining how OpenGL vNext was supposed to look like.

Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend.

> so each newbie

Vulkan isn't for newbies. Really, if you're new to 3D graphics then you're not Vulkan's target audience; pretending otherwise only results in pain. That's like complaining that a modern CPU's privileged instructions are too complicated for people new to assembly – yes, they are, and no, that's not a design flaw.

> Also Vulkan only exists because AMD was so kind to contribute Mantle as starting ground

That's maybe a point against Khronos, not against Vulkan.

> Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend.

Which is exactly what people should be doing. And those middleware engines can be written using Vulkan, because it is designed the way it is.

My degree thesis was porting a particle engine framework from NeXTSTEP/OpenGL/Objective-C into Windows/OpenGL/C++ with MFC.

Yet that doesn't mean I don't care about newbies in 2021, specially when Khronos says OpenGL isn't going to move beyond version 4.6, thus everyone new in the field feels like Vulkan is what they should learn instead.

> Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend.

Isn't this why Vulkan was designed the way it was. It's lower level, giving more control to things like memory. In this way I view it somewhat like the ASM of the GPU (even though though there are lower levels still).

I'm curious if anyone with a lot of experience writing graphics "middleware engine" backends agrees.

The idea was probably "built it and they will come" (the library authors who provide the easier to use wrapper libraries). The problem is that these libraries are hobbyist/volunteer work (with the notable exception of native WebGPU implementations), which on its own isn't a bad thing, but hobbyist can't afford a testing lab running hundreds of GPU/driver/OS combinations to make sure that their libraries are as robust as expected.

The companies who have these resources (for instance the GPU vendors), chickened out by designing Vulkan and thus offloading those QA tasks to the API users (simplified, but that's what it is in the end).

Which leaves Unity, Epic, and a handful AAA game developers as potential Vulkan users, which in turn are not enough to test Vulkan implementations, because just a handful API users isn't enough to cover all the dusty corners (same situation as back in the bad old days with MiniGL).

> Which leaves Unity, Epic, and a handful AAA game developers as potential Vulkan users

??? For example, there are a substantial number of emulators that have already implemented or are in the middle of implementing a Vulkan backend: RPCS3, Dolphin, Yuzu, Cemu, Ryujinx, PPSSPP... these emulators are developed by small teams but often push the hardware hard, bringing bugs to light in the process.

Also DXVK and VK3D.

Yeah exactly. Vulkan is meant to be the lowest level interface possible to the hardware. It's for programmers who hitting a wall in terms of optimization because of the overhead imposed by OpenGL or DX11. It's not intended for everyday programmers, and it would not make sense to make concessions in performance to accommodate usability concerns.

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.

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?

> Extension spaghetti for starters

Extensions are a PITA to deal with, but they generally represent real disparate hardware features offered by individual GPUs which varies by manufacturer, model, and date. This reminds me of CPU features like SSE2, AVX, AES, etc, etc which general-purpose binary programs are forced to query for at runtime to either take advantage of or fall back to a software implementation. But GPUs have even more architectural change velocity than CPUs.

It seems like a hard problem in general. How do you think this could be done better?

Yeah exactly. How else can you support the wide range of hardware features out there without being stuck with a lowest-common-denominator?

I think what pjmlp is trying to suggest is the API or Khronos instead of allowing extensions where it has limitless possibility, it should be courting and doing what Metal and Direct X are doing setting tiers of GPU Level. You either support RayTracing + N other features and call yourself Vulkan 2.0 GPU or you get back to Vulkan 1.x

This is exactly how is has been working in the PC world, and is working quite well as far as I can tell.

Apple, Microsoft, Sony and Nintendo have such a hard time delivering high quality graphics with their proprietary APIs, pity them.

"How do you support a wide variety of hardware with different features without API extensions?"

"Look at these companies that offer an API without extensions by not even trying to support hardware with different features."

PC, iOS and console AAA game studios are doing just fine with those APIs.

How does DX12 do feature discovery for things like ray tracing which are supported on only some hardware?

Haven't checked DX12 yet, but both D3D11 and Metal have a small number of "tiers" with guaranteed feature sets, which basically correspond to GPU generations. Usually you pick the lowest tier you can afford and write your code against that feature set.

In D3D11, the "tier" is basically the minor version number (D3D11.1, .2, etc...), while in Metal you have this handy reference:

https://developer.apple.com/metal/Metal-Feature-Set-Tables.p...

Both solutions prevent the "combinatorial explosion" of OpenGL or Vulkan extensions.

Ok I didn't know that, but it seems like a very sensible approach. I suppose you would lose some specificity in terms of very specific features, but probably this would be sufficient in most cases.

But couldn't you do something very similar in Vulkan? I.e. essentially bucket your render-paths into a couple tiers by checking for a set of extensions required to support each one?

By requiring DX12 Ultimate support, done.

This is a very low-quality argument. Game developers quite clearly cannot only target DX12 Ultimate and have their product only work for a small percentage of users on PC.

If you want to target PC, you have to deal with hardware fragmentation. You can pretend this is a Vulkan issue, but it's just a reality of the platform.

Nice story, except DirectX owns the PC market, period.

pjmlp I have been on this forum long enough to know you would eventually move the goalposts. Your claim was about the merit of extensions, I'm not sure why you're talking about marketshare now.

What goalposts? The APIs that own the games market are doing just fine without Khronos mess.

This is not feature discovery, though - this is feature constraining, which is rather different, and doesn't work at all if you want to get a game out to a large audience while also taking advantage of different hardware configurations.

It has done wonders for PC gaming so far.

Feature discovery has done wonders for PC gaming. Not feature constraint, like you're advocating.

Like proprietary APIs do it, there is a limited feature set and it is set, done.

With extension spaghetti, not only are we back in GLAD and GLEW land, each set of extensions is yet another possible code path.

Extensions are the stick with which hardware vendors beat platform companies (in practice, Microsoft) into innovation. That's how we got raytracing, for example.

Hardware raytracing was designed by NVidia and Microsoft together while creating DirectX 12 Ultimate, shown to the world in an Unreal engine based demo of a starwars lift scene, it has zero to do with Vulkan.

I doubt either of us were in the relevant rooms, but the API is very obviously a DX-ification of Nvidia's OptiX (the software-based raytracing solution that they released long before HW raytracing). Furthermore, Nvidia released OpenGL and Vulkan extensions for raytracing long before the release of DX12 Ultimate. Do you think Microsoft would have allowed that if it was a genuine co-development by the two companies?

> Followed by Khronos refusal that it isn't part of their job to define an SDK, so each newbie has to go through the ritual of passage to learn how to get OS abstraction libraries to show up a 3D accelerated window, math library, font handling library, texture and image loading library, shader compiling infrastructure, scene graph to handle meshes,

That seems to me like a reasonable decision that graphics API does not try to encompass and duplicate many other unrelated APIs and stays focused on graphics.

I completely agree. I recently decided to try learning Vulkan. I built an sdl window framework and got an OpenGL triangle in maybe 6 lines of OpenGL code. For vulkan you literally cannot draw anything until your reimplement an entire rendering engine from probing hardware, to figuring out queuing strategies, and resource management, etc. you are forced to focus your on HOW rather than WHAT to draw. I think they set the barrier of entry way too high. From a newbie perspective I’d rather have the library make smart decisions by default so I can just init and draw. But if I wanted to do more I could.

It takes dozens of lines of code to draw a triangle in modern OpenGL. You were presumably using immediate mode, which is ancient and deprecated because it has horrible performance on modern hardware. Given that the whole point of an API for hardware accelerated graphics is better performance, that's a big problem.

Immediate mode OpenGL not even a particularly friendly API, either. I found its implicit global mutable state for things like the matrix stack to be deeply confusing. There's much better drawing libraries out there if what you're looking for is ease-of-use.

The removal of immediate mode from OpenGL is one of many examples of modern OpenGL's stupidity, partially responsible for creating the mess we're in:

https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-...

Immediate mode still exists and is usable to this day. The compatibility profile never went away.

JWZ implemented old-school OpenGL in a library on top of a more modern API, and I would entirely agree that's a good approach to compatibility. I'd have advocated for doing the same thing, just without calling everyone idiots.

Immediate mode makes no sense from a performance standpoint. But you can still use it in 2021 if you want. I believe it's still supported mostly for CAD programs which haven't changed their core software since the 80's

And if you like the immediate mode API, just use something like raylib's rgl[1] that emulates an immediate-mode API on modern OpenGL. Aside from performance benefits, you can port your code to GLES or WebGL, where immediate-mode isn't present.

[1] https://github.com/raysan5/raylib/blob/master/src/rlgl.h

I'm willing to bet that much of that extra code you talk about is the boilerplate code that every Vulkan tutorial tells you is boilerplate code. After that boilerplate is cut and pasted in and you have your first triangle, what is the incremental in drawing a second triangle?