<p>Vulkan will not have the CPU-time performance costs associated with state changes (validation overhead, etc). But Vulkan command buffers do have state. They have two very major pieces of state: descriptor sets and the pipeline object.</p>

<p>Both of these objects are monolithic, dealing with potentially lots of pieces of information. The (potentially) huge quantity of stuff these objects control should strongly suggest to you that binding new objects is not cheap. And that's in terms of GPU execution speed, not CPU validation or whatever else.</p>

<p>Vulkan in general tries to make slow things in the API look slow and fast things look fast. Render passes are big, huge and complicated, so clearly you shouldn't just be starting and stopping them whenever you feel like it. Pipeline objects control a huge amount of information, so binding new ones feels like a heavyweight operation.</p>

<p>By contrast, changing what buffers get used for vertex input feels like a short, quick, <em>focused</em> operation. So it's probably cheaper than changing the pipeline that uses those buffers.</p>

<p>So yes, you should avoid state changes in Vulkan, just as much if not moreso than in OpenGL (since many state changes in Vulkan require entirely new pipelines).</p>

CC BY-SA 4.0
2020-06-04T18:13:36.623Z
I would imagine that state changes in the GPU are at least an order of magnitude faster compared to the old OpenGL way, correct me if I'm wrong. I make this question in reference to how easily you can attach materials and shaders to your models in the modern versions of unity and unreal engine - almost like the cost to manage those is nil. Regardless, your reply is pointing to further study on vulkan on my part.
GnoSiS
CC BY-SA 4.0
2020-06-12T15:51:56.970Z
@GnoSiS just because the software (API, game engine...) changed, does not mean your hardware (GPU, CPU... ) necessarily changed the same way. Asking processors to do less things, will always be faster than asking them to do more of the same things.
wip
CC BY-SA 4.0
2020-06-17T09:16:21.867Z
@wip true, but the design "distance" in years between vulkan and opengl is huge, so this implies a radically different aproach. I have no reference point on how faster is managing state changes in the GPU vs the CPU. I see people "preaching" vulkan alll around, but need to get the actual details right, before making decisions.
GnoSiS
CC BY-SA 4.0
2020-06-17T22:12:27.283Z
Vulkan is a standardized API, how fast it is in practice depends on how well GPU vendors implemented it in their drivers (and how well it matches their hardware design). A few years ago it was not rare to have OpenGL faster than Vulkan on some mobile phones. Hopefully the situation has improved now (the hardware also changed since then).
wip
CC BY-SA 4.0
2020-06-17T22:27:29.440Z
@GnoSiS: "*so this implies a radically different aproach*" It shouldn't. The API tells you (more or less) what is fast and slow. Slow things look slow, and fast things look fast. And no matter how "radically different" something might get, basic advice like "don't repeat stuff you don't have to" should be standard.
Nicol Bolas
CC BY-SA 4.0
2020-06-04T01:26:40.457Z
2020-06-04T01:26:40.457Z
Nicol Bolas
<p>This is in reference and contrast to the discipline (or more or less requirement) of opengl to group draws that use the same materials together, to minimize making many draw calls or many switch shader calls.</p>

<p>So is it safe to say, that since vulkan is not state/context based, you can throw any mixture of draw commands with multiple seperate shaders/materials in the command queue, with no slowdown or overhead impact, and that even if you did the grouping optimization, you wouldn't see a speedup as well?</p>

<vulkan><optimisation>
Do you have to group and optimize your draw and shader calls in Vulkan?
GnoSiS
# Do you have to group and optimize your draw and shader calls in Vulkan?

(Asked by: username_0 on 2020-06-03)

This is in reference and contrast to the discipline (or more or less requirement) of opengl to group draws that use the same materials together, to minimize making many draw calls or many switch shader calls.

So is it safe to say, that since vulkan is not state/context based, you can throw any mixture of draw commands with multiple seperate shaders/materials in the command queue, with no slowdown or overhead impact, and that even if you did the grouping optimization, you wouldn't see a speedup as well?

**Tags:** vulkan, optimisation


---

## 1 answers

### Answer by username_1 on 2020-06-04. Score: 2 | Accepted answer

Vulkan will not have the CPU-time performance costs associated with state changes (validation overhead, etc). But Vulkan command buffers do have state. They have two very major pieces of state: descriptor sets and the pipeline object.

Both of these objects are monolithic, dealing with potentially lots of pieces of information. The (potentially) huge quantity of stuff these objects control should strongly suggest to you that binding new objects is not cheap. And that's in terms of GPU execution speed, not CPU validation or whatever else.

Vulkan in general tries to make slow things in the API look slow and fast things look fast. Render passes are big, huge and complicated, so clearly you shouldn't just be starting and stopping them whenever you feel like it. Pipeline objects control a huge amount of information, so binding new ones feels like a heavyweight operation.

By contrast, changing what buffers get used for vertex input feels like a short, quick, *focused* operation. So it's probably cheaper than changing the pipeline that uses those buffers.

So yes, you should avoid state changes in Vulkan, just as much if not moreso than in OpenGL (since many state changes in Vulkan require entirely new pipelines).

> **Comments:**
> **username_0**: I would imagine that state changes in the GPU are at least an order of magnitude faster compared to the old OpenGL way, correct me if I'm wrong. I make this question in reference to how easily you can attach materials and shaders to your models in the modern versions of unity and unreal engine - almost like the cost to manage those is nil. Regardless, your reply is pointing to further study on vulkan on my part.  
> **username_2**: @username_0 just because the software (API, game engine...) changed, does not mean your hardware (GPU, CPU... ) necessarily changed the same way. Asking processors to do less things, will always be faster than asking them to do more of the same things.  
> **username_0**: @username_2 true, but the design "distance" in years between vulkan and opengl is huge, so this implies a radically different aproach. I have no reference point on how faster is managing state changes in the GPU vs the CPU. I see people "preaching" vulkan alll around, but need to get the actual details right, before making decisions.  
> **username_2**: Vulkan is a standardized API, how fast it is in practice depends on how well GPU vendors implemented it in their drivers (and how well it matches their hardware design). A few years ago it was not rare to have OpenGL faster than Vulkan on some mobile phones. Hopefully the situation has improved now (the hardware also changed since then).  
> **username_1**: @username_0: "*so this implies a radically different aproach*" It shouldn't. The API tells you (more or less) what is fast and slow. Slow things look slow, and fast things look fast. And no matter how "radically different" something might get, basic advice like "don't repeat stuff you don't have to" should be standard.  

---

