<p>Binding a Graphics Pipeline in Vulkan is considered to be an expensive operation. So performance can be an issue if a program wants to bind many pipelines for each frame. Binding hundreds or even a few thousand pipelines per a frame is reasonable, a high end system could support up into the tens of thousands (good luck getting anything else done though).</p>
<p>Alternatives:</p>
<p>Vulkan allows some parts of the pipeline to be dynamic, the list of what can be dynamic was recently extended as well. Using dynamic pipelines is less efficient then using a &quot;non&quot; dynamic pipes, but much more efficient then constantly binding many different pipelines.</p>
<p>Even if there are only a few pipelines per a frame, a program can still get into trouble by constantly switching between pipelines. So, combine draw calls on a per pipe basis, meaning bind a pipe, do all the draws for that pipe, bind the next pipe, etc.</p>
<p>Finding ways to merge shaders is probably the best way to reduce the number of pipelines. The extreme on this is the so called <em>uber</em> shader where virtually all the shaders are merged into a single shader. Just merging groups of similar shaders can greatly reduce the number of pipelines though and is usually fairly easy to do.</p>
<p>There is a little hand waving for this next one, but I have seen some programs with hardcoded descriptor values inside shaders which causes pipeline count to explode, just switching to multiple descriptor sets helps resolve this. This creates a system where a pipeline is bound, then each draw for that pipeline binds a descriptor set. (often there is a single descriptor set that has all the generic info in it, and a per draw set that has per draw specific info) This has its own drawbacks but is better then many graphics pipelines.</p>

CC BY-SA 4.0
2022-01-31T00:30:35.623Z
Isn't there a Vulkan equivalent of Nvidia bindless stuff? https://www.nvidia.com/en-us/drivers/bindless-graphics/ ; https://www.khronos.org/opengl/wiki/Bindless_Texture
got trolled too much this week
CC BY-SA 4.0
2022-01-31T00:36:21.207Z
Apparently there is https://wickedengine.net/2021/04/06/bindless-descriptors/ but I haven't used it myself, so can't comment in any depth.
got trolled too much this week
CC BY-SA 4.0
2022-01-31T01:43:15.300Z
Bindless has good support in Vulkan, combined with Vulkans memory management, compute shaders, and draw indirect a massive number of objects can be pushed through a pipeline.
pmw1234
CC BY-SA 4.0
2022-01-22T13:20:10.860Z
2022-01-22T13:20:10.860Z
pmw1234
<p>I would like to represent creation for each 2D shape or bitmap effect as a pipeline. The only purpose of this to modularize algorithms because extendibility is a big deal for current project. However, is there any drawback for using that kind of strategy? If it’s too risky (in term of performance and stability), then any other alternatives?</p>

<vulkan>
A lot of pipelines on Vulkan for each render pass, what could go wrong?
Thor-x86_128
# A lot of pipelines on Vulkan for each render pass, what could go wrong?

(Asked by: username_0 on 2022-01-22)

I would like to represent creation for each 2D shape or bitmap effect as a pipeline. The only purpose of this to modularize algorithms because extendibility is a big deal for current project. However, is there any drawback for using that kind of strategy? If it’s too risky (in term of performance and stability), then any other alternatives?

**Tags:** vulkan


---

## 1 answers

### Answer by username_1 on 2022-01-22. Score: 2 | Accepted answer

Binding a Graphics Pipeline in Vulkan is considered to be an expensive operation. So performance can be an issue if a program wants to bind many pipelines for each frame. Binding hundreds or even a few thousand pipelines per a frame is reasonable, a high end system could support up into the tens of thousands (good luck getting anything else done though).

Alternatives:

Vulkan allows some parts of the pipeline to be dynamic, the list of what can be dynamic was recently extended as well. Using dynamic pipelines is less efficient then using a "non" dynamic pipes, but much more efficient then constantly binding many different pipelines.

Even if there are only a few pipelines per a frame, a program can still get into trouble by constantly switching between pipelines. So, combine draw calls on a per pipe basis, meaning bind a pipe, do all the draws for that pipe, bind the next pipe, etc.

Finding ways to merge shaders is probably the best way to reduce the number of pipelines. The extreme on this is the so called *uber* shader where virtually all the shaders are merged into a single shader. Just merging groups of similar shaders can greatly reduce the number of pipelines though and is usually fairly easy to do.

There is a little hand waving for this next one, but I have seen some programs with hardcoded descriptor values inside shaders which causes pipeline count to explode, just switching to multiple descriptor sets helps resolve this. This creates a system where a pipeline is bound, then each draw for that pipeline binds a descriptor set. (often there is a single descriptor set that has all the generic info in it, and a per draw set that has per draw specific info) This has its own drawbacks but is better then many graphics pipelines.

> **Comments:**
> **username_2**: Isn't there a Vulkan equivalent of Nvidia bindless stuff? https://www.nvidia.com/en-us/drivers/bindless-graphics/ ; https://www.khronos.org/opengl/wiki/Bindless_Texture  
> **username_2**: Apparently there is https://wickedengine.net/2021/04/06/bindless-descriptors/ but I haven't used it myself, so can't comment in any depth.  
> **username_1**: Bindless has good support in Vulkan, combined with Vulkans memory management, compute shaders, and draw indirect a massive number of objects can be pushed through a pipeline.  

---

