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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
