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

[Tvrtko Ursulin <tursulin@igalia.com>]

On 10/12/2025 12:17, Saarinen, Jani wrote:
> Hi,
>
>> -----Original Message-----
>> From: Intel-xe <intel-xe-bounces@lists.freedesktop.org> On Behalf Of Tvrtko
>> Ursulin
>> Sent: Wednesday, 10 December 2025 12.08
>> To: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: intel-xe@lists.freedesktop.org; kernel-dev@igalia.com; Tvrtko Ursulin
>> <tvrtko.ursulin@igalia.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com>
>> Subject: Re: [PATCH v15 06/10] drm/xe: Handle DPT in system memory
>>
>>
>> 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.
>>
>> I even tried removing the clflush from i915 but I wasn't able to repro any
>> failures there. This may make it sound like the clflush isn't required, but
>> given I am not able to repro failures with xe either I think we cannot assume
>> this.
>>
>> On the overall ADL is not a supported platform with xe. So one option could
>> simply be to not complicate my series, allow for sporadic CI fails (record
>> them in CI bug log as expected), and revisit the topic
>> *if*/*when* a problem outside of CI is found.
>>
>> Also annoying is that ADL machines are in the xe CI and not i915. If they were
>> in i915 I would be able to do some CI runs to see if i915 can be made to fail
>> sporadically without the initial clflush.
> There are systems in i915 BAT but not in shards. Perhaps modify test list (BAT) and use that IGT for your kernel changes?

Okay I will try, thanks for the green light Jani. :)

Are they the same type machines/Alderlakes both in the i915 BAT and xe 
shards? Problem could be, as long as something is different, failure to 
trigger the sporadic fails in i915 BAT will not confirm i915 is immune 
to it.

Regards,

Tvrtko