[Intel-gfx] [PATCH 2/4] drm/i915/dsb: Correct DSB command buffer cache coherency settings

Ville Syrjälä ville.syrjala at linux.intel.com
Fri Oct 13 13:48:17 UTC 2023


On Thu, Oct 12, 2023 at 09:40:23PM +0000, Shankar, Uma wrote:
> 
> 
> > -----Original Message-----
> > From: Intel-gfx <intel-gfx-bounces at lists.freedesktop.org> On Behalf Of Ville
> > Syrjala
> > Sent: Monday, October 9, 2023 6:52 PM
> > To: intel-gfx at lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH 2/4] drm/i915/dsb: Correct DSB command buffer
> > cache coherency settings
> > 
> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > 
> > The display engine does not snoop the caches so shoukd to mark the DSB
> 
> Nit: Typo here
> 
> I am not sure on the cache behaviour so someone from core can also ack.
> To me , looks logically correct.
> Reviewed-by: Uma Shankar <uma.shankar at intel.com>

Thanks. This series is now merged. Fingers crossed DSB will behave
nicely...

> 
> > command buffer as I915_CACHE_NONE.
> > i915_gem_object_create_internal() always gives us I915_CACHE_LLC on LLC
> > platforms. And to make things 100% correct we should also clflush at the end, if
> > necessary.
> > 
> > Note that currently this is a non-issue as we always write the command buffer
> > through a WC mapping, so a cache flush is not actually needed. But we might
> > actually want to consider a WB mapping since we also end up reading from the
> > command buffer (in the indexed reg write handling). Either that or we should do
> > something else to avoid those reads (might actually be even more sensible on
> > DGFX since we end up reading over PCIe). But we should measure the overhead
> > first...
> > 
> > Anyways, no real harm in adding the belts and suspenders here so that the code
> > will work correctly regardless of how we map the buffer. If we do get a WC
> > mapping (as we request)
> > i915_gem_object_flush_map() will be a nop. Well, apart form a wmb() which may
> > just flush the WC buffer a bit earlier than would otherwise happen (at the latest
> > the mmio accesses would trigger the WC flush).
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_dsb.c | 15 +++++++++++----
> >  1 file changed, 11 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> > b/drivers/gpu/drm/i915/display/intel_dsb.c
> > index 7410ba3126f9..78b6fe24dcd8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> > @@ -316,6 +316,8 @@ void intel_dsb_finish(struct intel_dsb *dsb)
> >  				   DSB_FORCE_DEWAKE, 0);
> > 
> >  	intel_dsb_align_tail(dsb);
> > +
> > +	i915_gem_object_flush_map(dsb->vma->obj);
> >  }
> > 
> >  static int intel_dsb_dewake_scanline(const struct intel_crtc_state *crtc_state)
> > @@ -462,13 +464,18 @@ struct intel_dsb *intel_dsb_prepare(const struct
> > intel_crtc_state *crtc_state,
> >  	/* ~1 qword per instruction, full cachelines */
> >  	size = ALIGN(max_cmds * 8, CACHELINE_BYTES);
> > 
> > -	if (HAS_LMEM(i915))
> > +	if (HAS_LMEM(i915)) {
> >  		obj = i915_gem_object_create_lmem(i915, PAGE_ALIGN(size),
> > 
> > I915_BO_ALLOC_CONTIGUOUS);
> > -	else
> > +		if (IS_ERR(obj))
> > +			goto out_put_rpm;
> > +	} else {
> >  		obj = i915_gem_object_create_internal(i915, PAGE_ALIGN(size));
> > -	if (IS_ERR(obj))
> > -		goto out_put_rpm;
> > +		if (IS_ERR(obj))
> > +			goto out_put_rpm;
> > +
> > +		i915_gem_object_set_cache_coherency(obj,
> > I915_CACHE_NONE);
> > +	}
> > 
> >  	vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
> >  	if (IS_ERR(vma)) {
> > --
> > 2.41.0
> 

-- 
Ville Syrjälä
Intel


More information about the Intel-gfx mailing list