All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>,
	"Ville Syrjälä" <ville.syrjala@intel.com>,
	"Uma Shankar" <uma.shankar@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, Jani Nikula <jani.nikula@intel.com>
Subject: Re: ✗ Xe.CI.Full: failure for AuxCCS handling and render compression modifiers
Date: Tue, 4 Feb 2025 18:36:10 -0500	[thread overview]
Message-ID: <Z6KkahOKuiBTKDfX@intel.com> (raw)
In-Reply-To: <eb3a3729-e8ef-4868-b8ff-b6efd66ef4fa@igalia.com>

On Tue, Feb 04, 2025 at 11:12:45AM +0000, Tvrtko Ursulin wrote:
> 
> + Rodrigo and Jani for possible CI/display insights or adding correct Cc
> please.

+Ville, Uma

I never liked very much the crc checks, but I thought the pipe crc were
more reliable. I had a horrible experience with the edp sink crc in the
past...

more below...

> 
> On 31/01/2025 20:26, Patchwork wrote:
> > igt@kms_flip_tiling@flip-change-tiling@pipe-a-hdmi-a-1-y-rc-ccs-cc-to-y-mc-ccs (NEW):
> > 
> >   * shard-adlp: NOTRUN -> FAIL
> >     <https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-144186v1/shard-adlp-2/igt@kms_flip_tiling@flip-change-tiling@pipe-a-hdmi-a-1-y-rc-ccs-cc-to-y-mc-ccs.html> +66 other tests fail
> 
> Two things here.
> 
> First it seems to be some sort of a race condition in crc collection and/or
> vblank counter handling. Tests work individually but fail one run in
> sequence. Bad CRC also varies run to run, while visually things look fine to
> me on screen. Also a delay before collecting the crc seems to improve
> things.
> 
> I instrumented things a bit but I don't really understand it. For example
> collecting the reference CRC appears to have some "collect it at the next
> vblank logic", but I am not sure that works correctly. Ie.
> 
> Working case:
> ==========================================
> 
> Getting the reference CRC:
> ------------------------------------------
> (kms_flip_tiling:14174) igt_pipe_crc-DEBUG: crc for vblank 703868, target
> 703869; crc[0]=b82b36e4
> (kms_flip_tiling:14174) igt_pipe_crc-DEBUG: crc for vblank 703869, target
> 703869; crc[0]=b82b36e4
> 
> reference_crc[0]=b82b36e4
> 
> Compare after flip:
> 
> (kms_flip_tiling:14174) igt_pipe_crc-DEBUG: crc for vblank 703870, target
> 703872; crc[0]=b82b36e4
> (kms_flip_tiling:14174) igt_pipe_crc-DEBUG: crc for vblank 703871, target
> 703872; crc[0]=2aa66f1d
> (kms_flip_tiling:14174) igt_pipe_crc-DEBUG: crc for vblank 703872, target
> 703872; crc[0]=b82b36e4
> 
> reference_crc[0]=b82b36e4 crc[0]=b82b36e4
> 
> 
> Failing case:
> ==========================================
> 
> Getting the reference CRC:
> ------------------------------------------
> (kms_flip_tiling:14145) igt_pipe_crc-DEBUG: crc for vblank 698273, target
> 698278; crc[0]=b82b36e4
> (kms_flip_tiling:14145) igt_pipe_crc-DEBUG: crc for vblank 698274, target
> 698278; crc[0]=b82b36e4
> (kms_flip_tiling:14145) igt_pipe_crc-DEBUG: crc for vblank 698275, target
> 698278; crc[0]=b82b36e4
> (kms_flip_tiling:14145) igt_pipe_crc-DEBUG: crc for vblank 698276, target
> 698278; crc[0]=b82b36e4
> (kms_flip_tiling:14145) igt_pipe_crc-DEBUG: crc for vblank 698277, target
> 698278; crc[0]=b82b36e4
> (kms_flip_tiling:14145) igt_pipe_crc-DEBUG: crc for vblank 698278, target
> 698278; crc[0]=7b978b62
> 
> reference_crc[0]=7b978b62
> 
> Compare after flip:
> ------------------------------------------
> (kms_flip_tiling:14145) igt_pipe_crc-DEBUG: crc for vblank 698279, target
> 698281; crc[0]=dbec96bd
> (kms_flip_tiling:14145) igt_pipe_crc-DEBUG: crc for vblank 698280, target
> 698281; crc[0]=da444d0a
> (kms_flip_tiling:14145) igt_pipe_crc-DEBUG: crc for vblank 698281, target
> 698281; crc[0]=b82b36e4
> 
> reference_crc[0]=7b978b62 crc[0]=b82b36e4

This is pretty interesting.

b82b36e4 (vblank 698273 to 698277) = b82b36e4 (vblank 698281)

But the vblank 698278 came before the page flip, so, why was that different?
It doesn't look reliable. Should we then get a few samples and stick with
the most seen one? :(


> 
> (kms_flip_tiling:14145) igt_pipe_crc-DEBUG: CRC mismatch at index 0:
> 0x7b978b62 != 0xb82b36e4
> 
> Second thing - how come xe shards have ADL-P when xe does not support it,
> while i915 shards don't, when it does? :))
> 
> Regards,
> 
> Tvrtko

  reply	other threads:[~2025-02-04 23:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-31 14:20 [PATCH 0/2] AuxCCS handling and render compression modifiers Tvrtko Ursulin
2025-01-31 14:20 ` [PATCH 1/2] drm/xe/display: Add support for AuxCCS Tvrtko Ursulin
2025-01-31 14:20 ` [PATCH 2/2] drm/xe/display: Expose AuxCCS frame buffer modifiers Tvrtko Ursulin
2025-01-31 14:40 ` ✓ CI.Patch_applied: success for AuxCCS handling and render compression modifiers Patchwork
2025-01-31 14:41 ` ✗ CI.checkpatch: warning " Patchwork
2025-01-31 14:42 ` ✓ CI.KUnit: success " Patchwork
2025-01-31 14:58 ` ✓ CI.Build: " Patchwork
2025-01-31 15:00 ` ✓ CI.Hooks: " Patchwork
2025-01-31 15:02 ` ✓ CI.checksparse: " Patchwork
2025-01-31 15:22 ` ✓ Xe.CI.BAT: " Patchwork
2025-01-31 20:26 ` ✗ Xe.CI.Full: failure " Patchwork
2025-02-04 11:12   ` Tvrtko Ursulin
2025-02-04 23:36     ` Rodrigo Vivi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-10-20  7:58 [PATCH v13 00/12] " Tvrtko Ursulin
2025-10-20 14:52 ` ✗ Xe.CI.Full: failure for " Patchwork
2025-10-20 15:03   ` Tvrtko Ursulin
2025-10-24 10:47 [PATCH v14 00/13] " Tvrtko Ursulin
2025-10-24 23:57 ` ✗ Xe.CI.Full: failure for " Patchwork
2025-11-07 20:55   ` Tvrtko Ursulin
2025-12-08 19:17 [PATCH v15 00/10] " Tvrtko Ursulin
2025-12-09  3:28 ` ✗ Xe.CI.Full: failure for " Patchwork
2025-12-16 15:37 [PATCH v16 0/8] " Tvrtko Ursulin
2025-12-17 21:57 ` ✗ Xe.CI.Full: failure for " Patchwork
2026-03-19 10:06 [PATCH v23 00/12] " Tvrtko Ursulin
2026-03-20 11:38 ` ✗ Xe.CI.FULL: failure for " Patchwork
2026-03-20 17:02 [PATCH v24 00/12] *AuxCCS " Tvrtko Ursulin
2026-03-21 17:52 ` ✗ Xe.CI.FULL: failure for " Patchwork
2026-03-23  9:42   ` Tvrtko Ursulin
2026-03-23 22:11     ` Rodrigo Vivi
2026-03-24  8:25       ` Tvrtko Ursulin
2026-03-24  8:40 [PATCH v25 00/12] AuxCCS " Tvrtko Ursulin
2026-03-24 18:53 ` ✗ Xe.CI.FULL: failure for " 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=Z6KkahOKuiBTKDfX@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=tvrtko.ursulin@igalia.com \
    --cc=uma.shankar@intel.com \
    --cc=ville.syrjala@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.