[Impeller] Fix render pass layout transition when resolve texture has mip levels. #57211
Conversation
| TextureVK::Cast(*attachment.texture).GetLayout() // | ||
| attachment.store_action // | ||
| ); | ||
| TextureVK::Cast(*attachment.texture) |
There was a problem hiding this comment.
Since the render pass is cached and reused, these calls to SetLayoutWithoutEncoding were only running the first time. I moved them into the constructor so they correctly run each time.
This could be the cause of other bugs, as it could leave our own book keeping out of sync with the actual image layout.
| #include "impeller/renderer/backend/vulkan/sampler_vk.h" | ||
| #include "impeller/renderer/backend/vulkan/shared_object_vk.h" | ||
| #include "impeller/renderer/backend/vulkan/texture_vk.h" | ||
| #include "vulkan/vulkan.hpp" |
| #include "impeller/renderer/command_buffer.h" | ||
| #include "impeller/renderer/render_pass.h" | ||
| #include "impeller/renderer/render_target.h" | ||
| #include "vulkan/vulkan_handles.hpp" |
| pass_info.setClearValueCount(clear_count); | ||
|
|
||
| if (resolve_image_vk_) { | ||
| // If the resolve image has mip levels, only mip level 0 will be |
There was a problem hiding this comment.
Can we not make the pass perform the transition for all levels? In fact, I already think it does. The only way it may not is if the image descriptor doesn't contain the right mip count.
There was a problem hiding this comment.
That value can also be VK_REMAINING_MIP_LEVELS. But again, I suppose I don't know how we could only perform the transition for some levels.
|
I think I am missing something because I don't understand the underlying issue. |
|
@chinmaygarde I was planning to ask you about this. I think this might be something like a bug in the validation layers: when the render pass transitions mip level 0 of a texture to eGeneral, the remaining mipLevels are left in eUndefined. Its possible since the ImageView that the render pass uses only has one mip level this is WAI though, and the other mip levels must be transitioned manually. But it might not matter at all since we're going to blow away all the mip level content by populating them. |
2 participants
This fixed the validation error produced in 159876. Not clear yet if it fixes the actual rendering error.