public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maarten Lankhorst <dev@lankhorst.se>
Cc: "B, Jeevan" <jeevan.b@intel.com>,
	"Naladala, Ramanaidu" <ramanaidu.naladala@intel.com>,
	"igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>
Subject: Re: [PATCH i-g-t] tests/kms_cursor_legacy: Prefer tile4 modifier when supported
Date: Mon, 13 Apr 2026 12:29:52 +0300	[thread overview]
Message-ID: <ady3cgAzN2t-HCpH@intel.com> (raw)
In-Reply-To: <c60ad161-ae0a-47a3-acf0-85a517f6199e@lankhorst.se>

On Mon, Apr 13, 2026 at 11:21:09AM +0200, Maarten Lankhorst wrote:
> Hey,
> 
> My thoughts at the end, I think the focus on linear formats is misguided.

What's misguided is adding driver specific hacks to each and every
test. If we think that the default modifier used for most things
should be something other than linear, then we need to introduce
a proper driver agnostic mechanism tests can use to pick the preferred
modifier.

> 
> Den 2026-03-18 kl. 05:19, skrev B, Jeevan:
> > Hi Ramanaidu,
> > 
> >  
> > 
> > Apart from set_fb_on_crtc I don’t think we need to add this change anywhere else, There are few fb creation happening for cursor.
> > 
> >  
> > 
> > Thanks
> > 
> > Jeevan B
> > 
> >  
> > 
> > *From:*Naladala, Ramanaidu <ramanaidu.naladala@intel.com>
> > *Sent:* Wednesday, March 18, 2026 1:14 AM
> > *To:* B, Jeevan <jeevan.b@intel.com>; Ville Syrjälä <ville.syrjala@linux.intel.com>; Murthy, Arun R <arun.r.murthy@intel.com>
> > *Cc:* igt-dev@lists.freedesktop.org
> > *Subject:* Re: [PATCH i-g-t] tests/kms_cursor_legacy: Prefer tile4 modifier when supported
> > 
> >  
> > 
> > ++ Arun
> > 
> > Hi Ville,
> > 
> > On 3/16/2026 10:57 PM, B, Jeevan wrote:
> > 
> >         -----Original Message-----
> > 
> >         From: Ville Syrjälä <ville.syrjala@linux.intel.com> <mailto:ville.syrjala@linux.intel.com>
> > 
> >         Sent: Monday, March 16, 2026 8:15 PM
> > 
> >         To: B, Jeevan <jeevan.b@intel.com> <mailto:jeevan.b@intel.com>
> > 
> >         Cc: igt-dev@lists.freedesktop.org <mailto:igt-dev@lists.freedesktop.org>; Naladala, Ramanaidu
> > 
> >         <ramanaidu.naladala@intel.com> <mailto:ramanaidu.naladala@intel.com>
> > 
> >         Subject: Re: [PATCH i-g-t] tests/kms_cursor_legacy: Prefer tile4 modifier when
> > 
> >         supported
> > 
> >          
> > 
> >         On Mon, Mar 16, 2026 at 09:08:07AM +0530, Jeevan B wrote:
> > 
> >             While creating the framebuffer, prefer tile4 when it is supported
> > 
> >             instead of always using linear. Fall back to linear if tile4 is not
> > 
> >             available.
> > 
> >          
> > 
> >         Why?
> > 
> >     On Xe platforms, using the linear modifier takes longer to prepare and submit a flip compared to tiled modifiers. 
> > 
> >     On HRR panels, the available frame time is small, and this delay can cause flips to be submitted in the Evasion region, 
> > 
> >     leading to sequence mismatches.
> > 
> >  
> > 
> > Adding some points:
> > 
> > XE does not include memory optimizations for linear surfaces, which leads to higher processing time for linear buffers. Consequently, linear stress tests are intermittently failing.
> 
> I've been working on GGTT and pinning. The problem with linear pinning is
> that you pin the entire FB into GGTT, using uncached writes.
> 
> Compositors are already aware that linear framebuffers are slow on all
> drivers, not just xe, and will avoid using them at all costs.
> 
> The tests should similarly avoid using linear framebuffers, as they will
> not be representive of real workloads.
> Any non-linear modifier is good, 4-tiled probably bst.
> 
> If you keep using linear, the XRGB101010 format on a 4K monitor
> (3840x2160) would need to over 8000 uncached writes in a row into GGTT,
> stalling synchronously each time on the completion of the write by the
> display hardware.
> This only gets worse when you use other formats with the linear modifier.
> 
> If there is still a problem when using tiled modifiers, and tests
> continue to fail, I have some ideas to make DPT even faster, without
> requiring unbound usage of GGTT.
> 
> Acked-by: Maarten Lankhorst <dev@lankhorst.se>
> 
> Kind regards,
> ~Maarten Lankhorst

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2026-04-13  9:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-16  3:38 [PATCH i-g-t] tests/kms_cursor_legacy: Prefer tile4 modifier when supported Jeevan B
2026-03-16  5:17 ` ✓ Xe.CI.BAT: success for " Patchwork
2026-03-16  5:23 ` ✗ i915.CI.BAT: failure " Patchwork
2026-03-16  7:22 ` ✗ Xe.CI.FULL: " Patchwork
2026-03-16  8:07 ` [PATCH i-g-t] " Naladala, Ramanaidu
2026-03-16  8:15 ` Naladala, Ramanaidu
2026-03-16 14:44 ` Ville Syrjälä
2026-03-16 17:27   ` B, Jeevan
2026-03-17 19:44     ` Naladala, Ramanaidu
2026-03-18  4:19       ` B, Jeevan
2026-04-13  9:21         ` Maarten Lankhorst
2026-04-13  9:29           ` Ville Syrjälä [this message]
2026-04-13 10:28             ` Maarten Lankhorst
2026-03-18  9:44     ` Ville Syrjälä
2026-04-06  4:08 ` ✓ Xe.CI.BAT: success for tests/kms_cursor_legacy: Prefer tile4 modifier when supported (rev2) Patchwork
2026-04-06  4:19 ` ✓ i915.CI.BAT: " Patchwork
2026-04-06  5:13 ` ✓ Xe.CI.FULL: " Patchwork
2026-04-06  6:12 ` ✗ i915.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=ady3cgAzN2t-HCpH@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dev@lankhorst.se \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=jeevan.b@intel.com \
    --cc=ramanaidu.naladala@intel.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