[Mesa-dev] [PATCH v4 3/6] i965: Enable hardware-generated binding tables on render path.

[Chris Wilson]

On Fri, Jul 03, 2015 at 10:00:31AM +0300, Abdiel Janulgue wrote:
> +void
> +gen7_enable_hw_binding_tables(struct brw_context *brw)
> +{
> +   if (!brw->use_resource_streamer)
> +      return;
> +
> +   if (!brw->hw_bt_pool.bo) {
> +      /* We use a single re-usable buffer object for the lifetime of the
> +       * context and size it to maximum allowed binding tables that can be
> +       * programmed per batch:
> +       *
> +       * From the Haswell PRM, Volume 7: 3D Media GPGPU,
> +       * 3DSTATE_BINDING_TABLE_POOL_ALLOC > Programming Note:
> +       * "A maximum of 16,383 Binding tables are allowed in any batch buffer"
> +       */
> +      static const int max_size = 16383 * 4;
> +      brw->hw_bt_pool.bo = drm_intel_bo_alloc(brw->bufmgr, "hw_bt",
> +                                              max_size, 64);
> +      brw->hw_bt_pool.next_offset = 0;
> +   }
> +
> +   int pkt_len = brw->gen >= 8 ? 4 : 3;
> +   uint32_t dw1 = BRW_HW_BINDING_TABLE_ENABLE;
> +   if (brw->is_haswell)
> +      dw1 |= SET_FIELD(GEN7_MOCS_L3, GEN7_HW_BT_POOL_MOCS) |
> +         HSW_BT_POOL_ALLOC_MUST_BE_ONE;
> +   else if (brw->gen >= 8)
> +      dw1 |= BDW_MOCS_WB;
> +
> +   BEGIN_BATCH(pkt_len);
> +   OUT_BATCH(_3DSTATE_BINDING_TABLE_POOL_ALLOC << 16 | (pkt_len - 2));
> +   if (brw->gen >= 8) {
> +      OUT_RELOC64(brw->hw_bt_pool.bo, I915_GEM_DOMAIN_SAMPLER, 0, dw1);
> +      OUT_BATCH(brw->hw_bt_pool.bo->size);
> +   } else {
> +      OUT_RELOC(brw->hw_bt_pool.bo, I915_GEM_DOMAIN_SAMPLER, 0, dw1);
> +      OUT_RELOC(brw->hw_bt_pool.bo, I915_GEM_DOMAIN_SAMPLER, 0,
> +             brw->hw_bt_pool.bo->size);
> +   }
> +   ADVANCE_BATCH();
> +
> +   /* From the Haswell PRM, Volume 7: 3D Media GPGPU,
> +    * 3DSTATE_BINDING_TABLE_POOL_ALLOC > Programming Note:
> +    *
> +    * "When switching between HW and SW binding table generation, SW must
> +    * issue a state cache invalidate."
> +    */
> +   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_STATE_CACHE_INVALIDATE);

Should this flush not be before the enable? It's a top-of-pipe sync,
which means that the enable 3DSTATE will be parsed and changing the GPU
state as the previous commands are still running. Since the flush is
mandatory, that implies to me that the state it changing is not latched
and so still being used by those earlier commands.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre