Re: [PATCH] drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches

On Fri, 2026-08-14 at 12:17 +0200, Thomas Hellström wrote:
> emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to
> flush the L2/HDC data cache before fence signalling, but it never
> requests a flush of the LSC untyped L1 data cache via the 'Untyped
> Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11].
> 
> Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented
> to
> also flush/invalidate the untyped L1 cache, but only depending on how
> HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling
> between HDC Pipeline Flush and the untyped L1 cache flush no longer
> holds in practice, regardless of how HDC_CHICKEN0 is programmed, so
> relying on it is not safe on newer platforms such as BMG. Mesa's
> Vulkan
> driver (anv) has been assuming the kernel flushes both caches between
> submissions, and hit user-visible corruption in apps such as
> Llama.cpp
> because of this gap; it now works around it by flushing both caches
> again from userspace at the end of every command buffer.
> 
> Fix it in the kernel instead: explicitly set
> PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together with
> PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush(), so
> callers waiting on this flush (e.g. end of batch, before releasing
> memory for reuse) can rely on both the L2 and L1 data caches being
> clean, without depending on undocumented platform-specific
> HDC_CHICKEN0 behavior or requiring a userspace workaround.
> 
> Fixes: 9f8f93bee3ef ("drm/xe: Emit a render cache flush after each
> rcs/ccs batch")
> Reported-by: Lionel Landwerlin <[email protected]>
> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8909
> Cc: José Roberto de Souza <[email protected]>
> Cc: [email protected]
> Cc: <[email protected]> # v6.8+
> Assisted-by: GitHub_Copilot:claude-sonnet-5
> Signed-off-by: Thomas Hellström <[email protected]>
> ---
>  drivers/gpu/drm/xe/instructions/xe_gpu_commands.h | 1 +
>  drivers/gpu/drm/xe/xe_ring_ops.c                  | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xe/instructions/xe_gpu_commands.h
> b/drivers/gpu/drm/xe/instructions/xe_gpu_commands.h
> index 18d0fde8c98f..faf8d7e2c5c1 100644
> --- a/drivers/gpu/drm/xe/instructions/xe_gpu_commands.h
> +++ b/drivers/gpu/drm/xe/instructions/xe_gpu_commands.h
> @@ -46,6 +46,7 @@
>  #define
> GFX_OP_PIPE_CONTROL(len)	((0x3<<29)|(0x3<<27)|(0x2<<24)|((len)-2))
>  
>  #define   PIPE_CONTROL0_QUEUE_DRAIN_MODE		BIT(12)
> +#define	 
> PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH	BIT(11)	/* gen12 */
>  #define	 
> PIPE_CONTROL0_L3_READ_ONLY_CACHE_INVALIDATE	BIT(10)	/* gen12 */
>  #define	 
> PIPE_CONTROL0_HDC_PIPELINE_FLUSH		BIT(9)	/* gen12 */
>  
> diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c
> b/drivers/gpu/drm/xe/xe_ring_ops.c
> index 39a670e91ba7..79511de558d9 100644
> --- a/drivers/gpu/drm/xe/xe_ring_ops.c
> +++ b/drivers/gpu/drm/xe/xe_ring_ops.c
> @@ -219,7 +219,8 @@ static int emit_render_cache_flush(struct
> xe_sched_job *job, u32 *dw, int i)
>  		i = emit_pipe_control(dw, i, 0,
> PIPE_CONTROL_DEPTH_CACHE_FLUSH,
>  				     
> LRC_PPHWSP_FLUSH_INVAL_SCRATCH_ADDR, 0);
>  
> -	flags0 = PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
> +	flags0 = PIPE_CONTROL0_HDC_PIPELINE_FLUSH |
> +		PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH;

My only concern is this programming note:

This bit is functional and must be only set for GPGPU workloads, i.e
when PIPELINE_SELECT command has set Pipeline Select mode set to GPGPU.

Spec is not 100% clear but looks like setting it in 3D mode would be
nop.

So if this don't cause any regression this is:


Reviewed-by: José Roberto de Souza <[email protected]>

>  	flags1 = (PIPE_CONTROL_TILE_CACHE_FLUSH |
>  		 PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
>  		 PIPE_CONTROL_DEPTH_CACHE_FLUSH |