Re: [PATCH v4 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

[Chris Wilson <chris.p.wilson@intel.com>]

Quoting Akeem G Abodunrin (2020-02-20 23:00:23)
> +static void emit_batch(struct i915_vma * const vma,
> +                      u32 *start,
> +                      const struct batch_vals *bv)
> +{
> +       struct drm_i915_private *i915 = vma->vm->i915;
> +       unsigned int desc_count = 64;
> +       const u32 urb_size = 112;
> +       struct batch_chunk cmds, state;
> +       u32 interface_descriptor;
> +       unsigned int i;
> +
> +       batch_init(&cmds, vma, start, 0, bv->cmd_size);
> +       batch_init(&state, vma, start, bv->state_start, bv->state_size);
> +
> +       interface_descriptor =
> +               gen7_fill_interface_descriptor(&state, bv,
> +                                              IS_HASWELL(i915) ?
> +                                              &cb_kernel_hsw :
> +                                              &cb_kernel_ivb,
> +                                              desc_count);

Negligible in the grand scheme of things, but there was a
STATE_CACHE_INVALIDATION flush just prior to this batch.

> +       gen7_emit_pipeline_flush(&cmds);
> +       batch_add(&cmds, PIPELINE_SELECT | PIPELINE_SELECT_MEDIA);
> +       batch_add(&cmds, MI_NOOP);

What's the reason for the noop here?

> +       gen7_emit_state_base_address(&cmds, interface_descriptor);
> +       gen7_emit_pipeline_flush(&cmds);

And iirc, this is recommended for SBI. Does this flush require a
CS_STALL?

> +       gen7_emit_vfe_state(&cmds, bv, urb_size - 1, 0, 0);
> +
> +       gen7_emit_interface_descriptor_load(&cmds,
> +                                           interface_descriptor,
> +                                           desc_count);
> +
> +       for (i = 0; i < bv->max_primitives; i++)
> +               gen7_emit_media_object(&cmds, i);
> +
> +       batch_add(&cmds, MI_BATCH_BUFFER_END);
> +}

I can't comment on the efficacy of the kernels, but the code is finally
passing CI and the batch takes long enough that it has to be doing
something! Just running a giant loop mostly.

Acked-by: Chris Wilson <chris.p.wilson@intel.com>
-Chris
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel