diff options
| author | Samuel Pitoiset <[email protected]> | 2018-04-17 15:08:11 +0200 |
|---|---|---|
| committer | Samuel Pitoiset <[email protected]> | 2018-04-19 09:09:55 +0200 |
| commit | 796b6f4aab46924f9954c9b2a9821b4706618cab (patch) | |
| tree | c6d9744f7c99d612d22fe257f41fa18a4c1618df | |
| parent | 4a698660aef46475e9bb49a03eb1019792f478c2 (diff) | |
radv: make sure to sync after resolving using the compute path
This fixes some random CTS failures:
dEQP-VK.renderpass.multisample.*.
Performing a fast-clear eliminate is still useless, but it
seems that we need to sync.
Found while running CTS with RADV_DEBUG=zerovram.
Fixes: 56a171a499c ("radv: don't fast-clear eliminate after resolving a subpass with compute")
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
| -rw-r--r-- | src/amd/vulkan/radv_meta_resolve_cs.c | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/src/amd/vulkan/radv_meta_resolve_cs.c b/src/amd/vulkan/radv_meta_resolve_cs.c index 628208d6356..ede55f6d005 100644 --- a/src/amd/vulkan/radv_meta_resolve_cs.c +++ b/src/amd/vulkan/radv_meta_resolve_cs.c @@ -516,5 +516,8 @@ radv_cmd_buffer_resolve_subpass_cs(struct radv_cmd_buffer *cmd_buffer) &(VkExtent2D) { fb->width, fb->height }); } + cmd_buffer->state.flush_bits |= RADV_CMD_FLAG_CS_PARTIAL_FLUSH | + RADV_CMD_FLAG_INV_VMEM_L1; + radv_meta_restore(&saved_state, cmd_buffer); } |