[iamcornholio]

I also disagree with some statements about Vulkan API. My two cents: > The docs are written in a sort of alien English that fosters no understanding— but it's also written exactly the way a hardware implementor would want in order to remove all ambiguity about what a function call does. In short, Vulkan is not for you. It is a byzantine contract between hardware manufacturers and middleware providers, and people like… well, me, are just not part of the transaction.

Vulkan is a Standard. It uses standardese language to define things. It defines all the relevant concepts like instance, physical device, logical device, command pools and buffers, etc. (Vulkan is not that different in this regard from other standards like C Language Standard, or C++ Language Standard).

The Standard also explains how this different concepts relate to each other, how GPU and Host interoperate, how memory flows, how synchronization works.

For example, it explains that there is a thing called instance, then this instance allows you to enumerate physical devices and obtain their properties, it explains that such devices have queues which can execute work. Then one or more physical devices can be used to create a logical device, which is a sort of lightweight context object. Then this logical device is used for allocating different resources, building pipelines, etc.

> Every Vulkan call involves passing in one or two huge structures which are themselves a forest of other huge structures, and every structure and sub-structure begins with a little protocol header explaining what it is and how big it is. Before you allocate memory you have to fill out a structure to get back a structure that tells you what structure you're supposed to structure your memory allocation request in....

Vulkan IS cumbersome to write using just C API, yes, but when you write actual program you usually wrap this functionality in a thin layer, and then suddenly everything becomes a lot less cumbersome. For example, you write initialization code exactly once, tailored for you specific needs, then wrap it in a function.

Construction of all of the pipelines, render passes, command buffers, etc. can also be wrapped in much the same way.

For example, construction of buffers and textures requires 3 steps: 1. creation of buffer/image object; 2. memory allocation; 3. binding memory to the object.

This functionality can be trivially wrapped in a function, then used many times. Then there are some libs like VulkanMemoryAllocator which simplify writing Vulkan even more. Memory synchronization is explained in https://github.com/KhronosGroup/Vulkan-Docs/wiki/Synchroniza...

The thing is, Vulkan requires planning. So if you want to write some simple game which displays sprites on the screen, then you are better off with something OpenGL-like. But once you need an optimized rendering pipeline with HiZ culling, minimal CPU-GPU memory transfers, etc., then Vulkan is the way to go. You can use newer OpenGL versions for this, but the code becomes much like something you would write using Vulkan API anyway.

[badsectoracula]

> Vulkan is a Standard. It uses standardese language to define things. It defines all the relevant concepts like instance, physical device, logical device, command pools and buffers, etc.

FWIW i also disagree with the article on that front. I wrote a simple demo of Vulkan[0] the day the specs became available and was able to learn it (or enough of it to write the demo) just by reading the specs themselves - i remember finding them very easy to read. However i already had graphics programming knowledge using OpenGL for many years before that - but it isn't like someone is going to learn graphics programming from OpenGL's spec either, there is/was the Red Book for that.

That said, i agree that Vulkan itself is cumbersome to write - and really why i never bothered with it after writing the demo and getting my feet wet with it. IMO...

> Vulkan IS cumbersome to write using just C API, yes, but when you write actual program you usually wrap this functionality in a thin layer, and then suddenly everything becomes a lot less cumbersome. [..] Construction of all of the pipelines, render passes, command buffers, etc. can also be wrapped in much the same way.

...having to paper over an API to hide its guts doesn't exactly sound good for that API's design. Personally at least i never felt i had to paper over OpenGL, or even the little (pre-12) Direct3D code i wrote.

[0] https://i.imgur.com/rd8Xk84.gif

[flohofwoe]

> Vulkan is a Standard. It uses standardese language to define things.

As a counter example, the "D3D Engineering Specs" do the same job, but are much more readable:

https://microsoft.github.io/DirectX-Specs/

PS:

> You can use newer OpenGL versions for this, but the code becomes much like something you would write using Vulkan API anyway.

Ironically, a lot of "modern" Vulkan might end up looking like old-school OpenGL again by using this new extension ;)

https://registry.khronos.org/vulkan/specs/1.3-extensions/man...

[Shugyousha]

> As a counter example, the "D3D Engineering Specs" do the same job, but are much more readable:

DirectX is not a standard so I don't think that makes this comparable. Most likely fewer people will have to read and implement it.

[mschuetz]

The issue with Vulkan is that it's so cumbersome, I just don't want to use it at all. Tried to switch, but went back to OpenGL. There isn't anything in Vulkan that warrants that insane amount of overhead.

WebGPU is based on similar modern paradigms but it's an actually usable, sane, not overly verbose API. It's a pitty that WebGPU is deliberately gutted to make it a 5 year old smartphone graphics API because I'd prefer it over Vulkan any day.

I'm glad that Vulkan is taking some steps back on render passes, pipelines, etc. If they keep removing unnecessary entry barriers, I might eventually try the switch again in a few years.

[pjmlp]

> Vulkan IS cumbersome to write using just C API, yes, but when you write actual program you usually wrap this functionality in a thin layer, and then suddenly everything becomes a lot less cumbersome. For example, you write initialization code exactly once, tailored for you specific needs, then wrap it in a function.

It follows the tradition of Khronos APIs, having each developer writing that thin layer as rite of passage, one must earn their stripes to use Khronos APIs.