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

[Abdiel Janulgue]

On 07/03/2015 12:20 PM, Chris Wilson wrote:
> 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.

I made a test-run with the flush first before the enable hw-bt and
didn't see any problems. Re-ordering this to the top does actually makes
sense. Thanks for pointing this out!

-Abdiel