Tips and Tricks: Vulkan Dos and Don'ts

Originally published at:

The increased performance potential of modern graphics APIs is coupled with a dramatically increased level of developer responsibility. Optimal use of Vulkan is not a trivial concept, especially in the context of a large engine, and information about how to maximize performance is still somewhat sparse. The following document is a compilation of wisdom from…

When you say "Switching tessellation and geometry shaders on/off is an expensive operation," does that apply to the situation where you bind two consecutive pipelines per frame, one with a shader that uses the geometry or tesselation stage, and the other that doesn't? To clarify, each frame you'd bind the first, draw, then the second, draw, present, and repeat. Is there a better way to do this if you have some scene geometry that requires those stages and others scene geometry that doesn't? Surely it wouldn't be better to have those stages active as passthroughs even on the geometry that doesn't use them?

What about the number of pipelines: Is it better to make one big pipeline with many DS bindings and draw calls, or should we make many little pipelines with minimal draw calls? How many pipelines per frame are reasonable?

Sorry but I find this confusing:
"Work Submission" section
DO (last item) Reuse command buffers when possible.
DON'T (4th item) Don't design around lots of command buffer reuse.
Maybe it's the "design around" term. Is the correct meaning: "Don't avoid, in your design, lots of command buffer reuse"?
That's what I'm assuming!

Reuse command buffers when possible, but do not base system design decisions around enabling reuse.

Hello there. What a nice article. The markup is broken here btw:

  • Group barriers in one call to vkCmdPipelineBarrier(). This way the worst case can be picked instead of sequentially going through all barriers.

best regards,

@cmdfreak – Good catch, thanks! It’s now fixed.