Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: intel-xe@lists.freedesktop.org, kernel-dev@igalia.com
Subject: Re: [PATCH v5 14/16] drm/xe: Force flush system memory AuxCCS framebuffers before scan out
Date: Fri, 4 Apr 2025 19:20:29 +0300	[thread overview]
Message-ID: <Z_AGzT44PmAp9JFk@intel.com> (raw)
In-Reply-To: <20250403190317.6064-15-tvrtko.ursulin@igalia.com>

On Thu, Apr 03, 2025 at 08:03:14PM +0100, Tvrtko Ursulin wrote:
> Even though frame buffer objects are created as write-combined, in
> practice, on top of all the ring buffer flushing, an additional clflush
> seems to be needed before display engine can coherently scan out the
> AuxCCS compressed data without transient artifacts.
> 
> If for comparison we look at how i915 handles things (where AuxCCS works
> fine), as it happens it has this same clflush before a frame buffer is
> pinned for display for the first time, courtesy the dynamic tracking of
> the buffer cache mode and setting the latter to uncached before handing
> to display.
> 
> Since xe considers the buffer object caching mode as static we can
> implement the same approach by adding a flag telling us if the buffer
> was ever pinned for display and flush on the first pin. Subsequent re-pins
> will not repeat the clflush but so far I have not observed any glitching
> after the first pin.

This doesn't make any sense to me. If you need a cflush for this 
then you should need a clflush for all framebuffers.

So feels like there's some kind of coherency bug somewhere. What
that would be I'm not sure. Eg. I don't recall there being a separate
MOCS field for aux. And clearly if you just have to do this for the
first pin then we must be using correct UC accesses for subsequent
rendering.

intel_fb_bo_framebuffer_init() also seems to have some hacks for
the case when the SCANOUT flag wasn't already set at time of
creation, but it doesn't do anything with caching stuff AFAICS.
So if you create a bo w/o the SCANOUT flag, dirty the caches,
and then feed it to the display do you see the cache dirt?

> 
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> ---
>  drivers/gpu/drm/xe/display/xe_fb_pin.c | 13 +++++++++++++
>  drivers/gpu/drm/xe/xe_bo_types.h       | 14 +++++++++-----
>  2 files changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> index d11a003880dc..13030fd2728a 100644
> --- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
> +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> @@ -332,6 +332,7 @@ static struct i915_vma *__xe_pin_fb_vma(const struct intel_framebuffer *fb,
>  	struct i915_vma *vma = kzalloc(sizeof(*vma), GFP_KERNEL);
>  	struct drm_gem_object *obj = intel_fb_bo(&fb->base);
>  	struct xe_bo *bo = gem_to_xe_bo(obj);
> +	bool first_pin;
>  	int ret;
>  
>  	if (!vma)
> @@ -363,6 +364,9 @@ static struct i915_vma *__xe_pin_fb_vma(const struct intel_framebuffer *fb,
>  	if (ret)
>  		goto err;
>  
> +	first_pin = !bo->display_pin;
> +	bo->display_pin = true;
> +
>  	if (IS_DGFX(xe))
>  		ret = xe_bo_migrate(bo, XE_PL_VRAM0);
>  	else
> @@ -383,6 +387,15 @@ static struct i915_vma *__xe_pin_fb_vma(const struct intel_framebuffer *fb,
>  
>  	/* Ensure DPT writes are flushed */
>  	xe_device_l2_flush(xe);
> +
> +	/*
> +	 * Force flush frame buffer data for non-coherent display access when
> +	 * AuxCCS formats are used.
> +	 */
> +	if (first_pin && !xe_bo_is_vram(bo) && !xe_bo_is_stolen(bo) &&
> +	    intel_fb_is_ccs_modifier(fb->base.modifier))
> +		drm_clflush_sg(xe_bo_sg(bo));
> +
>  	return vma;
>  
>  err_unpin:
> diff --git a/drivers/gpu/drm/xe/xe_bo_types.h b/drivers/gpu/drm/xe/xe_bo_types.h
> index 15a92e3d4898..b900cb290b01 100644
> --- a/drivers/gpu/drm/xe/xe_bo_types.h
> +++ b/drivers/gpu/drm/xe/xe_bo_types.h
> @@ -68,11 +68,6 @@ struct xe_bo {
>  	struct llist_node freed;
>  	/** @update_index: Update index if PT BO */
>  	int update_index;
> -	/** @created: Whether the bo has passed initial creation */
> -	bool created;
> -
> -	/** @ccs_cleared */
> -	bool ccs_cleared;
>  
>  	/**
>  	 * @cpu_caching: CPU caching mode. Currently only used for userspace
> @@ -84,6 +79,15 @@ struct xe_bo {
>  	/** @devmem_allocation: SVM device memory allocation */
>  	struct drm_gpusvm_devmem devmem_allocation;
>  
> +	/** @created: Whether the bo has passed initial creation */
> +	bool created : 1;
> +
> +	/** @ccs_cleared */
> +	bool ccs_cleared : 1;
> +
> +	/** @display_pin: Was it ever pinned to display */
> +	bool display_pin : 1;
> +
>  	/** @vram_userfault_link: Link into @mem_access.vram_userfault.list */
>  		struct list_head vram_userfault_link;
>  
> -- 
> 2.48.0

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2025-04-04 16:20 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-03 19:03 [PATCH v5 00/16] AuxCCS handling and render compression modifiers Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 01/16] drm/xe: Adjust ringbuf emission for maximum possible size Tvrtko Ursulin
2025-04-15 11:59   ` Francois Dugast
2025-04-15 12:40     ` Tvrtko Ursulin
2025-04-15 14:21       ` Lucas De Marchi
2025-04-03 19:03 ` [PATCH v5 02/16] drm/xe: Use emit_flush_imm_ggtt helper instead of open coding Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 03/16] drm/xe/xelpg: Flush CCS when flushing caches Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 04/16] drm/xe: Flush L3 when flushing render cache Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 05/16] drm/xe/xelp: Quiesce memory traffic before invalidating auxccs Tvrtko Ursulin
2025-04-04 15:44   ` Ville Syrjälä
2025-04-03 19:03 ` [PATCH v5 06/16] drm/xe/xelp: Support auxccs invalidation on blitter Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 07/16] drm/xe/xelp: Use MI_FLUSH_DW_CCS on auxccs platforms Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 08/16] drm/xe/xelp: Wait for AuxCCS invalidation to complete Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 09/16] drm/xe/xelp: Add AuxCCS invalidation to the buffer migration path Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 10/16] drm/xe: Use fb cached min alignment Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 11/16] drm/xe: Reduce DPT table alignment as in i915 Tvrtko Ursulin
2025-04-04 15:52   ` Ville Syrjälä
2025-04-03 19:03 ` [PATCH v5 12/16] drm/xe: Flush GGTT writes after populating DPT Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 13/16] drm/xe: Handle DPT in system memory Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 14/16] drm/xe: Force flush system memory AuxCCS framebuffers before scan out Tvrtko Ursulin
2025-04-04 16:20   ` Ville Syrjälä [this message]
2025-04-14  9:44     ` Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 15/16] drm/xe/display: Add support for AuxCCS Tvrtko Ursulin
2025-04-03 19:03 ` [PATCH v5 16/16] drm/i915/display: Expose AuxCCS frame buffer modifiers for Xe Tvrtko Ursulin
2025-04-04  2:19 ` ✓ CI.Patch_applied: success for AuxCCS handling and render compression modifiers (rev5) Patchwork
2025-04-04  2:19 ` ✗ CI.checkpatch: warning " Patchwork
2025-04-04  2:21 ` ✓ CI.KUnit: success " Patchwork
2025-04-04  2:37 ` ✓ CI.Build: " Patchwork
2025-04-04  2:40 ` ✓ CI.Hooks: " Patchwork
2025-04-04  2:41 ` ✓ CI.checksparse: " Patchwork
2025-04-04  3:27 ` ✓ Xe.CI.BAT: " Patchwork
2025-04-04 12:03 ` ✗ Xe.CI.Full: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z_AGzT44PmAp9JFk@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=kernel-dev@igalia.com \
    --cc=tvrtko.ursulin@igalia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox