Re: [PATCH v15 06/10] drm/xe: Handle DPT in system memory

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Dec 10, 2025 at 11:07:48AM +0100, Tvrtko Ursulin wrote:
> 
> On 09/12/2025 15:25, Ville Syrjälä wrote:
> > On Tue, Dec 09, 2025 at 03:10:03PM +0100, Tvrtko Ursulin wrote:
> >> On 09/12/2025 10:54, Ville Syrjälä wrote:
> >>> On Mon, Dec 08, 2025 at 08:17:17PM +0100, Tvrtko Ursulin wrote:
> >>>> From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> >>>>
> >>>> If DPT is allocated from system memory it will be created in the default
> >>>> write-back cached mode. This means we need to flush it after populating
> >>>> otherwise nothing works.
> >>>>
> >>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> >>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >>>> ---
> >>>>    drivers/gpu/drm/xe/display/xe_fb_pin.c | 4 ++++
> >>>>    1 file changed, 4 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> >>>> index a22a9182dadb..89ee68c40329 100644
> >>>> --- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
> >>>> +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> >>>> @@ -3,6 +3,7 @@
> >>>>     * Copyright © 2021 Intel Corporation
> >>>>     */
> >>>>    
> >>>> +#include <drm/drm_cache.h>
> >>>>    #include <drm/ttm/ttm_bo.h>
> >>>>    
> >>>>    #include "i915_vma.h"
> >>>> @@ -162,6 +163,9 @@ static int __xe_pin_fb_vma_dpt(const struct intel_framebuffer *fb,
> >>>>    					  rot_info->plane[i].dst_stride);
> >>>>    	}
> >>>>    
> >>>> +	if (!xe_bo_is_vram(dpt) && !xe_bo_is_stolen(dpt))
> >>>> +		drm_clflush_virt_range(dpt->vmap.vaddr, dpt_size);
> >>> How is anything working currently if the DPT is being
> >>> created with the wrong caching mode?
> >> I suspect the stolen allocation never fails in practice (or almost
> >> never, or at least not in CI).
> >>> Sounds like someone should fix the DPT creation to correctly
> >>> ask for UC/WC. But I suppose someone should measure if WB+flush
> >>> is actually faster...
> >> I am not sure what is desired here. System memory buffers defaulting to
> >> cached is the xe default, so should DPT be an exception I do not know.
> > Anything meant for the display engine is supposed to be uncached.
> 
> I can add XE_BO_FLAG_SCANOUT to the system memory buffer creation and 
> that would handle this aspect. Acceptable to you?
> 
>   But..
> 
> >
> >> In any case AuxCCS seems to only work with DPT in system memory and this
> >> clflush. DPT in stolen with GTT access and GTT flushing (as i915 does
> >> it) does not seem to work for xe. I guess the entity doing the DPT reads
> >> is somehow special coherency wise.
> > Sounds like there is still something broken in xe.
> 
> ... Issue is when you found the magic mocs 61 the CI still saw a 
> sporadic failure. 3 out of 44 new tests failed. These sporadic CI fails 
> I was never able to reproduce locally. (It was always ADL-P, and I have 
> an ADL-P as well.)
> 
> Above coupled with the fact i915 has this clflush on the first pin, I 
> assumed CCS is just special enough that it is required. For certain with 
> it there are no sporadic CI fails.

clflush does nothing for the display engine. If it helps then
I think there must be dirty cachelines around. I don't see how
anything else could explain it.

One would think it should be possible to even see such dirt right
after allocating a new BO and handing it to the display engine
without touching it in any way (IIRC even reads through the GMADR
aperture trigger cache flushes).

-- 
Ville Syrjälä
Intel