+ TU_CMD_DIRTY_COMPUTE_PIPELINE = 1 << 1,
+ TU_CMD_DIRTY_VERTEX_BUFFERS = 1 << 2,
+ TU_CMD_DIRTY_DESCRIPTOR_SETS = 1 << 3,
+ TU_CMD_DIRTY_COMPUTE_DESCRIPTOR_SETS = 1 << 4,
+ TU_CMD_DIRTY_SHADER_CONSTS = 1 << 5,
+ TU_CMD_DIRTY_STREAMOUT_BUFFERS = 1 << 6,
+ /* all draw states were disabled and need to be re-enabled: */
+ TU_CMD_DIRTY_DRAW_STATE = 1 << 7,
+};
+
+struct tu_streamout_state {
+ uint16_t stride[IR3_MAX_SO_BUFFERS];
+ uint32_t ncomp[IR3_MAX_SO_BUFFERS];
+ uint32_t prog[IR3_MAX_SO_OUTPUTS * 2];
+ uint32_t prog_count;
+ uint32_t vpc_so_buf_cntl;
+};
+
+/* There are only three cache domains we have to care about: the CCU, or
+ * color cache unit, which is used for color and depth/stencil attachments
+ * and copy/blit destinations, and is split conceptually into color and depth,
+ * and the universal cache or UCHE which is used for pretty much everything
+ * else, except for the CP (uncached) and host. We need to flush whenever data
+ * crosses these boundaries.
+ */
+
+enum tu_cmd_access_mask {
+ TU_ACCESS_UCHE_READ = 1 << 0,
+ TU_ACCESS_UCHE_WRITE = 1 << 1,
+ TU_ACCESS_CCU_COLOR_READ = 1 << 2,
+ TU_ACCESS_CCU_COLOR_WRITE = 1 << 3,
+ TU_ACCESS_CCU_DEPTH_READ = 1 << 4,
+ TU_ACCESS_CCU_DEPTH_WRITE = 1 << 5,
+
+ /* Experiments have shown that while it's safe to avoid flushing the CCU
+ * after each blit/renderpass, it's not safe to assume that subsequent
+ * lookups with a different attachment state will hit unflushed cache
+ * entries. That is, the CCU needs to be flushed and possibly invalidated
+ * when accessing memory with a different attachment state. Writing to an
+ * attachment under the following conditions after clearing using the
+ * normal 2d engine path is known to have issues:
+ *
+ * - It isn't the 0'th layer.
+ * - There are more than one attachment, and this isn't the 0'th attachment
+ * (this seems to also depend on the cpp of the attachments).
+ *
+ * Our best guess is that the layer/MRT state is used when computing
+ * the location of a cache entry in CCU, to avoid conflicts. We assume that
+ * any access in a renderpass after or before an access by a transfer needs
+ * a flush/invalidate, and use the _INCOHERENT variants to represent access
+ * by a transfer.
+ */
+ TU_ACCESS_CCU_COLOR_INCOHERENT_READ = 1 << 6,
+ TU_ACCESS_CCU_COLOR_INCOHERENT_WRITE = 1 << 7,
+ TU_ACCESS_CCU_DEPTH_INCOHERENT_READ = 1 << 8,
+ TU_ACCESS_CCU_DEPTH_INCOHERENT_WRITE = 1 << 9,