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@xxxxxxxxxxxxxxxxxx > > > [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14725/shard-snb7/igt@gem_eio@xxxxxxxxxxxxxxxxxx > > > > > > * 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14725/shard-iclb8/igt@kms_plane@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > > 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
