On 31/03/17 16:17, Jason Ekstrand wrote:
Cc: "13.0 17.0" <mesa-sta...@lists.freedesktop.org>
---
src/intel/vulkan/genX_cmd_buffer.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 1ce549a..b5297f4 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -597,6 +597,18 @@ genX(BeginCommandBuffer)(
genX(cmd_buffer_emit_state_base_address)(cmd_buffer);
+ /* We sometimes store vertex data in the dynamic state buffer for blorp
+ * operations and our dynamic state stream may re-use data from previous
+ * command buffers. In order to prevent stale cache data, we flush the VF
+ * cache. We could do this on every blorp call but that's not really
+ * needed as all of the data will get written by the CPU prior to the GPU
+ * executing anything. The chances are fairly high that they will use
+ * blorp at least once per primary command buffer so it shouldn't be
+ * wasted.
+ */
It took me some time to understand why this is just needed for primary
buffers.
If I had to come up with a comment, this is how I would put it :
Lifecycles of primary & secondary buffers are tied together when
CmdExecuteCommands() records commands of the later into the former.
Once recorded into a primary command buffer the secondary command
buffers cannot be destroyed/reset before the primary is.
Meaning none of the dynamic state addresses used in either buffer cannot
be reused before primary is destroyed/reset.
As a result the only point at which we can get stale data in the VF
cache is at the beginning of the primary buffer.
If that matches your understanding, this is :
Reviewed-by: Lionel Landwerlin <lionel.g.landwer...@intel.com>
+ if (cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_PRIMARY)
+ cmd_buffer->state.pending_pipe_bits |= ANV_PIPE_VF_CACHE_INVALIDATE_BIT;
+
VkResult result = VK_SUCCESS;
if (cmd_buffer->usage_flags &
VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT) {
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
