Re: ✗ Fi.CI.IGT: failure for series starting with [1/9] drm/i915: Expose 10:10:10 XRGB formats on SNB-BDW sprites (rev2)

[Petri Latvala <petri.latvala@intel.com>]

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.


-- 
Petri Latvala
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx