Ugh... I think as a rule, I think I'd rather set them to NULL and just
re-emit on the primary if we have to. Also, there is probably other state
we're not resetting and/or marking dirty. I'll give it a think. Thanks
for catching this!
--Jason
On January 4, 2018 08:16:35 Alex Smith <[email protected]> wrote:
After executing a secondary command buffer, we need to update certain
state on the primary command buffer to reflect changes by the secondary.
Otherwise subsequent commands may not have the correct state set.
This fixes various issues (rendering errors, GPU hangs) seen after
executing secondary command buffers in some cases.
Signed-off-by: Alex Smith <[email protected]>
Cc: [email protected]
---
src/intel/vulkan/genX_cmd_buffer.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 0bd3874db7..f6129f9d67 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -1056,6 +1056,14 @@ genX(CmdExecuteCommands)(
}
anv_cmd_buffer_add_secondary(primary, secondary);
+
+ /* Make sure state on the primary reflects any state that was set by
+ * the secondary. If the secondary didn't set these, they will be at
+ * their default values, so we will re-set them next time they're
+ * needed on the primary.
+ */
+ primary->state.current_pipeline = secondary->state.current_pipeline;
+ primary->state.current_l3_config = secondary->state.current_l3_config;
}
/* Each of the secondary command buffers will use its own state base
--
2.13.6
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
