Trying to make Vulkan a single API that covers everything from low-end mobile to high-end desktop was probably a mistake, in practice it has split into wildly distinct dialects for low-end and high-end targets anyway. Maybe one day we'll get a Vulkan 2.0 which ratchets up the mandatory baseline hardware features to something reasonably modern and removes all the API cruft needed to accommodate less capable hardware.
In hindsight, adding the RenderPass API to in Vulkan 1.0 support mobile chips was probably a mistake.
Vulkan 1.3 without render passes ("dynamic rendering") is so much easier, it reduces hundreds if not thousands of lines of code from the boilerplate code required to draw a triangle. And it gets even better in a practical project because you'd need to set up new render passes up front for every new thing you add.
Mobile vendors are catching up and providing means of getting advantage of tiler GPUs without the old verbose render pass API, but it's not there yet. And it'll take a while until mobile drivers propagate to the hands of consumers.
What's desperately needed is a way for compute shaders to read on-chip tile memory like Metal Tile shaders on macos/ios. That would finally bridge the gap, getting rid of the render pass mess altogether and provide a way to get the best perf on mobile chips without having to write a whole separate path for compositing/deferred lighting etc.
Because currently you get the best perf on desktop with compute shaders but mobile requires you to use fragment shaders to benefit from tile memory.
That said, Vulkan 1.3 is a massive improvement over 1.0.
I don't see a benefit in making a version 2.0 that's incompatible with 1.x, because it's not like vendors could stop shipping 1.x due to all the content using it out there.
> I don't see a benefit in making a version 2.0 that's incompatible with 1.x, because it's not like vendors could stop shipping 1.x due to all the content using it out there.
If we're going to keep piling features onto Vulkan 1.0 forever then I think we are least need much better onboarding resources, there's still a ton of introductory Vulkan material out there which dives into the older more verbose approaches and probably scares most people away immediately. The API is intimidating enough without immediately dumping render passes on beginners.
I totally agree, and so do the people working on it as well as some of the volunteers who write tutorials.
There's an ongoing effort to create beginner friendly introductory material which was discussed in the recent Vulkanised conference. And an effort to make a better documentation site that's easier to browse than the specification https://docs.vulkan.org/
On the volunteer front, there's a Vulkan 1.3 -based introductory tutorial (work in progress) over at https://vkguide.dev/
With regards to your comment, I think that "piling features on top of 1.0" is a mischaracterization, because a lot of the new features essentially replace old features, often making things a lot easier. For example, timeline semaphores (new sync primitive) essentially replace binary semaphores, fences and events (old sync primitives). Dynamic rendering replaces render passes. And so on.
I think there should be a Vulkan tutorial that doesn't start with the boring stuff of initialization and window creation. It's stuff that you write once and forget about, and nothing particularly interesting happens in it.
Looking at my hobby project, excluding the boring stuff (which is reusable), a "hello compute" example is around 100 LOC and a "hello triangle" around 120 LOC. GLSL shader sources included.
Maybe someday I'll get around to writing a "learn Vulkan the hard way" blog post with examples.
In hindsight the separation of GL and GLES was pointless IMHO (at least up to 2.x).
It led to GPU vendors to only offer GLES drivers besides the GPU supporting GL (according both the marketing and https://github.com/ptitSeb/gl4es) and made porting standard linux apps to arm platforms needlessly difficult. Note that even with GL4es you have to port the shaders manually to GLES.
> Trying to make Vulkan a single API that covers everything from low-end mobile to high-end desktop was probably a mistake, in practice it has split into wildly distinct dialects for low-end and high-end targets anyway.
Lots of people are continuing to make this mistake.
Things like "windowing init" libraries, for example, want to abstract over desktop, mobile, and web/WASM.
Sadly, the interaction mechanisms and lifetime management are sufficiently different that either you wind up with huge complications or the least common denominator is really low.
Even the way the profiles got introduced, I must think it was a joke on us.
Instead of dealing with specific API settings, like in proprietary APIs, there is the expectation to generate JSON configurations, parse them, generate code calling the profile API to configure the desired profile.
At Vulkanised 2024 there is a 1h long session on how to use them.
