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.
Comments
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.
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.