<p>You're sort of asking two different questions here but that's okay.</p>

<p>Changing Sampler states is pretty straightforward. When you create a descriptor set, you write your <code>VkSampler</code> object that you've created into a descriptor set. If you want to update a sampler in a descriptor set, create a <code>VkSampler</code> with the sampler settings you want and then call <code>vkUpdateDescriptorSets</code> with the new <code>VkSampler</code> writes that you want to perform. When you bind that descriptor set again it should contain your new sampler. This is a bit roundabout but you have to architect for it. You probably don't want to update samplers every frame so only do this when you need to. This is not an extremely expensive operation if you do it right. Vulkan expects descriptor set data to change; so long as that data lines up with the descriptor set layout it's going to go pretty fast. </p>

<p>Changing Pipelines is EXTREMELY expensive. Vulkan doesn't like to perform context switches like this so you can't just <em>update</em> an existing pipeline that's in use. You do have to completely rebuild your rendering path to use the new PSO. If you want to change between a few different Pipelines it's best to build them all upfront, build all the different command buffers that use the different pipelines and then execute the command buffer that has the pipeline you want to run. If you want to change your pipeline, execute the other command buffer that uses the pipeline you want. </p>

<p>Vulkan wants you to create, cache and reuse data as much as possible. That's how you get a lot of savings. You don't need to update descriptor sets, command buffers etc. unless they actually change. </p>

CC BY-SA 3.0
2017-01-09T21:06:17.350Z
Thank you very much! You saved me some headache's. You are right. I completely overseen the vkUpdateDescriptorSets method. And in my setup, the pipelines won't change at all. So I can build them all upfront.
char8_t
CC BY-SA 4.0
2022-03-29T08:15:43.627Z
When you say changing pipelines is extremely expensive, you mean compiling it, right? Simply binding a pipeline in the command buffer will not be expensive at all, right? It should be just a pointer to the program it should run, I think....
Zebrafish
CC BY-SA 4.0
2022-03-30T15:34:22.187Z
Changing the pipeline state object on a command buffer does happen instantly but what's expensive about it is what happens in the driver/ on the gpu. Changing the pipeline state requires the driver/gpu to flush its state which is what's expensive. Ideally on a command buffer you want to record all usage of a pipeline state directly after that pipeline state is bound. If you record command buffers where you keep binding a new pipeline state you're going to see serious performance problems.
Honeybunch
CC BY-SA 3.0
2017-01-09T20:11:42.203Z
2017-01-09T20:11:42.203Z
Honeybunch
<p>I have problems implementing a Vulkan renderer alongside my OpenGL one.</p>

<p>In OpenGL one can change sampler parameters easily at runtime (like anisotropy settings through glTexParameter) or blend/depth states.</p>

<p>I wonder if this is also possible in Vulkan.</p>

<p>I usually create lets say a sampler object with all information needed and throw the creation info away after construction.</p>

<p>I did not find any information on this on the net.</p>

<p>So, is there any way to change those settings at runtime or do I have to create a complete new sampler object down the road?</p>

<p>The same question applies to depth/blend states in pipeline objects.</p>

<p>I think the second case would not actually be particularly fast performance wise.</p>

<vulkan>
How to change sampler/pipeline states at runtime in Vulkan?
char8_t
# How to change sampler/pipeline states at runtime in Vulkan?

(Asked by: username_0 on 2017-01-09)

I have problems implementing a Vulkan renderer alongside my OpenGL one.

In OpenGL one can change sampler parameters easily at runtime (like anisotropy settings through glTexParameter) or blend/depth states.

I wonder if this is also possible in Vulkan.

I usually create lets say a sampler object with all information needed and throw the creation info away after construction.

I did not find any information on this on the net.

So, is there any way to change those settings at runtime or do I have to create a complete new sampler object down the road?

The same question applies to depth/blend states in pipeline objects.

I think the second case would not actually be particularly fast performance wise.

**Tags:** vulkan


---

## 1 answers

### Answer by username_1 on 2017-01-09. Score: 3 | Accepted answer

You're sort of asking two different questions here but that's okay.

Changing Sampler states is pretty straightforward. When you create a descriptor set, you write your `VkSampler` object that you've created into a descriptor set. If you want to update a sampler in a descriptor set, create a `VkSampler` with the sampler settings you want and then call `vkUpdateDescriptorSets` with the new `VkSampler` writes that you want to perform. When you bind that descriptor set again it should contain your new sampler. This is a bit roundabout but you have to architect for it. You probably don't want to update samplers every frame so only do this when you need to. This is not an extremely expensive operation if you do it right. Vulkan expects descriptor set data to change; so long as that data lines up with the descriptor set layout it's going to go pretty fast.

Changing Pipelines is EXTREMELY expensive. Vulkan doesn't like to perform context switches like this so you can't just *update* an existing pipeline that's in use. You do have to completely rebuild your rendering path to use the new PSO. If you want to change between a few different Pipelines it's best to build them all upfront, build all the different command buffers that use the different pipelines and then execute the command buffer that has the pipeline you want to run. If you want to change your pipeline, execute the other command buffer that uses the pipeline you want.

Vulkan wants you to create, cache and reuse data as much as possible. That's how you get a lot of savings. You don't need to update descriptor sets, command buffers etc. unless they actually change.

> **Comments:**
> **username_0**: Thank you very much! You saved me some headache's. You are right. I completely overseen the vkUpdateDescriptorSets method. And in my setup, the pipelines won't change at all. So I can build them all upfront.  
> **username_2**: When you say changing pipelines is extremely expensive, you mean compiling it, right? Simply binding a pipeline in the command buffer will not be expensive at all, right? It should be just a pointer to the program it should run, I think....  
> **username_1**: Changing the pipeline state object on a command buffer does happen instantly but what's expensive about it is what happens in the driver/ on the gpu. Changing the pipeline state requires the driver/gpu to flush its state which is what's expensive. Ideally on a command buffer you want to record all usage of a pipeline state directly after that pipeline state is bound. If you record command buffers where you keep binding a new pipeline state you're going to see serious performance problems.  

---

