From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Arkadiusz Hiler <arkadiusz.hiler@intel.com>,
Tomi Sarvela <tomi.p.sarvela@intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: ✗ Fi.CI.IGT: failure for series starting with [1/9] drm/i915: Expose 10:10:10 XRGB formats on SNB-BDW sprites (rev2)
Date: Tue, 15 Oct 2019 14:51:09 +0300 [thread overview]
Message-ID: <20191015115109.GA1208@intel.com> (raw)
In-Reply-To: <20191015092559.GL4019@platvala-desk.ger.corp.intel.com>
On Tue, Oct 15, 2019 at 12:25:59PM +0300, Petri Latvala wrote:
> On Tue, Oct 15, 2019 at 09:41:20AM +0300, Arkadiusz Hiler wrote:
> > On Mon, Oct 14, 2019 at 10:23:42PM +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 09, 2019 at 09:12:23PM -0000, Patchwork wrote:
> > > > == Series Details ==
> > > >
> > > > Series: series starting with [1/9] drm/i915: Expose 10:10:10 XRGB formats on SNB-BDW sprites (rev2)
> > > > URL : https://patchwork.freedesktop.org/series/67741/
> > > > State : failure
> > > >
> > > > == Summary ==
> > > >
> > > > CI Bug Log - changes from CI_DRM_7042_full -> Patchwork_14725_full
> > > > ====================================================
> > > >
> > > > Summary
> > > > -------
> > > >
> > > > **FAILURE**
> > > >
> > > > Serious unknown changes coming with Patchwork_14725_full absolutely need to be
> > > > verified manually.
> > > >
> > > > If you think the reported changes have nothing to do with the changes
> > > > introduced in Patchwork_14725_full, please notify your bug team to allow them
> > > > to document this new failure mode, which will reduce false positives in CI.
> > > >
> > > >
> > > >
> > > > Possible new issues
> > > > -------------------
> > > >
> > > > Here are the unknown changes that may have been introduced in Patchwork_14725_full:
> > > >
> > > > ### IGT changes ###
> > > >
> > > > #### Possible regressions ####
> > > >
> > > > * igt@gem_eio@in-flight-1us:
> > > > - shard-snb: [PASS][1] -> [FAIL][2]
> > > > [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7042/shard-snb7/igt@gem_eio@in-flight-1us.html
> > > > [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14725/shard-snb7/igt@gem_eio@in-flight-1us.html
> > > >
> > > > * igt@kms_plane@pixel-format-pipe-a-planes:
> > > > - shard-iclb: [PASS][3] -> [FAIL][4] +13 similar issues
> > > > [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7042/shard-iclb7/igt@kms_plane@pixel-format-pipe-a-planes.html
> > > > [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14725/shard-iclb8/igt@kms_plane@pixel-format-pipe-a-planes.html
> > >
> > > IGT-Version: 1.24-ge501741f
> > > ...
> > > Testing format AR30(0x30335241) / modifier 0x100000000000003 on A.0
> > > (kms_plane:1411) igt_fb-CRITICAL: Conversion not implemented (from format 0x30335241 to 0x78464749)
> > >
> > > DRM_FORMAT_ARGB2101010 = 0x30335241
> > > IGT_FORMAT_FLOAT = 0x78464749
> > >
> > > { .name = "ARGB2101010", .depth = 30, .drm_id = DRM_FORMAT_ARGB2101010,
> > > .pixman_id = PIXMAN_a2r10g10b10,
> > >
> > > { .name = "IGT-FLOAT", .depth = -1, .drm_id = IGT_FORMAT_FLOAT,
> > > .pixman_id = PIXMAN_rgba_float,
> > >
> > > if ((drm_format_to_pixman(cvt->src.fb->drm_format) != PIXMAN_invalid) &&
> > > (drm_format_to_pixman(cvt->dst.fb->drm_format) != PIXMAN_invalid)) {
> > > cnvert_pixman(cvt);
> > > return;
> > > ...
> > > igt_assert_f(false, "Conversion not implemented ...);
> > >
> > > So wtf?
> > >
> > > Are we somehow compiling igt with an old pixman causing
> > > #if PIXMAN_VERSION < PIXMAN_VERSION_ENCODE(0, 36, 0)
> > > #define PIXMAN_rgba_float PIXMAN_invalid
> > > #endif
> > > to happen?
> >
> > oof, seems like the building machine got downgraded somehow
> >
> > ci-worker1:~$ dpkg -l '*pixman*'
> > Desired=Unknown/Install/Remove/Purge/Hold
> > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> > ||/ Name Version Architecture Description
> > +++-===============================================-============================-============================-===================================================================================================
> > ii libpixman-1-0:amd64 0.34.0-2 amd64 pixel-manipulation library for X and cairo
> > ii libpixman-1-dev:amd64 0.34.0-2 amd64 pixel-manipulation library for X and cairo (development files)
> >
> > that's bad...
> >
> > > But the reference run shows it testing all the fancy YUV formats so
> > > I don't think that can be the case.
> >
> > That's the weird bit...
> >
> > Anyway the building machine needs updating and apt-mark hold.
> > This can cause fallout and we need to file bugs to limit the noise.
> >
> > There is quite some queue right now, but hopefully by tomorrow it will
> > be drained. I'll do the necessary updates and force IGT run to see what
> > is going to happen in the morning. Then I'll rerun this series.
> >
>
>
> I don't think the builder ever had a higher version.
>
> The fancy YUV formats work because the runtime lib is new enough, and
> the build-time checks for those are as such:
>
> #if CAIRO_VERSION < CAIRO_VERSION_ENCODE(1, 17, 2)
> /*
> * We need cairo 1.17.2 to use HDR formats, but the only thing added is a value
> * to cairo_format_t.
> *
> * To prevent going outside the enum, make cairo_format_t an int and define
> * ourselves.
> */
>
> #define CAIRO_FORMAT_RGB96F (6)
> #define CAIRO_FORMAT_RGBA128F (7)
> #define cairo_format_t int
> #endif
>
>
> and
>
>
> igt_skip_on_f(status == CAIRO_STATUS_INVALID_FORMAT &&
> cairo_version() < CAIRO_VERSION_ENCODE(1, 17, 2),
> "Cairo version too old, need 1.17.2, have %s\n",
> cairo_version_string());
>
> igt_skip_on_f(status == CAIRO_STATUS_NO_MEMORY &&
> pixman_version() < PIXMAN_VERSION_ENCODE(0, 36, 0),
> "Pixman version too old, need 0.36.0, have %s\n",
> pixman_version_string());
>
>
>
>
> In other words, the backwards compatibility for the fancy YUV formats
> at build-time was easy to sneak in by defining some values, is that
> possible to do with the 10bpc stuff? PIXMAN_rgba_float seems to be
> just PIXMAN_FORMAT_BYTE(128, PIXMAN_TYPE_RGBA_FLOAT,32,32,32,32),
> where PIXMAN_TYPE_RGBA_FLOAT is 11.
Hmm, yeah I suppose I can try to go that route instead.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-10-15 11:51 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 16:14 [PATCH 1/9] drm/i915: Expose 10:10:10 XRGB formats on SNB-BDW sprites Ville Syrjala
2019-10-08 16:14 ` [PATCH 2/9] drm/i915: Expose alpha formats on VLV/CHV primary planes Ville Syrjala
2019-10-29 10:01 ` Shankar, Uma
2019-10-29 10:01 ` [Intel-gfx] " Shankar, Uma
2019-10-08 16:14 ` [PATCH 3/9] drm/i915: Add missing 10bpc formats for pipe B sprites on CHV Ville Syrjala
2019-10-29 11:53 ` Shankar, Uma
2019-10-29 11:53 ` [Intel-gfx] " Shankar, Uma
2019-10-08 16:14 ` [PATCH 4/9] drm/i915: Expose C8 on VLV/CHV sprite planes Ville Syrjala
2019-10-29 10:29 ` Shankar, Uma
2019-10-29 10:29 ` [Intel-gfx] " Shankar, Uma
2019-10-08 16:14 ` [PATCH 5/9] drm/i915: Add 10bpc formats with alpha for icl+ Ville Syrjala
2019-10-09 10:43 ` [PATCH v2 " Ville Syrjala
2019-10-29 12:08 ` Shankar, Uma
2019-10-29 12:08 ` [Intel-gfx] " Shankar, Uma
2019-10-29 20:07 ` [PATCH " Juha-Pekka Heikkila
2019-10-29 20:07 ` [Intel-gfx] " Juha-Pekka Heikkila
2019-10-08 16:14 ` [PATCH 6/9] drm/i915: Sort format arrays consistently Ville Syrjala
2019-10-27 20:53 ` Juha-Pekka Heikkila
2019-10-27 20:53 ` [Intel-gfx] " Juha-Pekka Heikkila
2019-10-29 12:10 ` Shankar, Uma
2019-10-29 12:10 ` [Intel-gfx] " Shankar, Uma
2019-10-08 16:14 ` [PATCH 7/9] drm/i915: Reject ckey+fp16 on skl+ Ville Syrjala
2019-10-29 13:07 ` Shankar, Uma
2019-10-29 13:07 ` [Intel-gfx] " Shankar, Uma
2019-10-29 13:35 ` Shankar, Uma
2019-10-29 13:35 ` [Intel-gfx] " Shankar, Uma
2019-10-29 15:22 ` Ville Syrjälä
2019-10-29 15:22 ` [Intel-gfx] " Ville Syrjälä
2019-10-30 15:26 ` Shankar, Uma
2019-10-30 15:26 ` [Intel-gfx] " Shankar, Uma
2019-10-08 16:14 ` [PATCH 8/9] drm/i915: Do not enable HDR mode when color keying is active Ville Syrjala
2019-10-29 13:22 ` Shankar, Uma
2019-10-29 13:22 ` [Intel-gfx] " Shankar, Uma
2019-10-08 16:14 ` [PATCH 9/9] drm/i915: Eliminate redundancy in intel_primary_plane_create() Ville Syrjala
2019-10-27 20:53 ` Juha-Pekka Heikkila
2019-10-27 20:53 ` [Intel-gfx] " Juha-Pekka Heikkila
2019-10-29 13:24 ` Shankar, Uma
2019-10-29 13:24 ` [Intel-gfx] " Shankar, Uma
2019-10-08 18:24 ` ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Expose 10:10:10 XRGB formats on SNB-BDW sprites Patchwork
2019-10-09 0:55 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-10-09 15:45 ` ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Expose 10:10:10 XRGB formats on SNB-BDW sprites (rev2) Patchwork
2019-10-09 21:12 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-10-14 19:23 ` Ville Syrjälä
2019-10-14 20:23 ` Chris Wilson
2019-10-15 6:41 ` Arkadiusz Hiler
2019-10-15 9:25 ` Petri Latvala
2019-10-15 11:51 ` Ville Syrjälä [this message]
2019-10-15 12:08 ` Arkadiusz Hiler
2019-10-29 9:08 ` [PATCH 1/9] drm/i915: Expose 10:10:10 XRGB formats on SNB-BDW sprites Shankar, Uma
2019-10-29 9:08 ` [Intel-gfx] " Shankar, Uma
2019-10-29 20:15 ` Juha-Pekka Heikkila
2019-10-29 20:15 ` [Intel-gfx] " Juha-Pekka Heikkila
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=20191015115109.GA1208@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=arkadiusz.hiler@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tomi.p.sarvela@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