In Skia, we were running into a rendering bug where we would render to a VkImage and then immediately do another draw to a second VkImage sampling the first as a texture (with memory barrier in between). All our draws go through secondary command buffers. On certain hardware, the effects of draws to the first VkImage were not there when we sampled it in the next draw (we would just get whatever values were in the VkImage previously). We had double checked all our memory barriers and other synchronization, ran all the code through the SDK debug layers, and other general debugging and none of this showed any sort of error on our part.
After patching the above fix to flush before execute the secondary buffers, all our unit and rendering tests started passing/drawing correctly. Greg On Fri, Mar 24, 2017 at 7:33 PM Jason Ekstrand <[email protected]> wrote: This apparently fixes rendering corruptions on the Vulkan port of Skia on some hardware. On Fri, Mar 24, 2017 at 4:31 PM, Jason Ekstrand <[email protected]> wrote: Cc: "13.0 17.0" <[email protected]> --- src/intel/vulkan/genX_cmd_buffer.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c index e2364db..8ec882e 100644 --- a/src/intel/vulkan/genX_cmd_buffer.c +++ b/src/intel/vulkan/genX_cmd_buffer.c @@ -654,6 +654,11 @@ genX(CmdExecuteCommands)( */ genX(cmd_buffer_enable_pma_fix)(primary, false); + /* The secondary command buffer doesn't know which textures etc. have been + * flushed prior to their execution. Apply those flushes now. + */ + genX(cmd_buffer_apply_pipe_flushes)(primary); + for (uint32_t i = 0; i < commandBufferCount; i++) { ANV_FROM_HANDLE(anv_cmd_buffer, secondary, pCmdBuffers[i]); -- 2.5.0.400.gff86faf
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
