Bug 110357 - [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration
Summary: [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" co...
Alias: None
Product: Mesa
Classification: Unclassified
Component: EGL (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
Depends on:
Blocks: 102590
  Show dependency treegraph
Reported: 2019-04-08 16:53 UTC by Andrés Gómez García
Modified: 2019-09-18 18:07 UTC (History)
9 users (show)

See Also:
i915 platform:
i915 features:


Description Andrés Gómez García 2019-04-08 16:53:19 UTC


commit dacb11a585face5ca179c34cfc588a71a425c1e0
Author: Eric Anholt <eric@anholt.net>
Date:   Sat Aug 25 14:16:59 2018 -0700

    egl: Add a 565 pbuffer-only EGL config under X11.
    The CTS requires a 565-no-depth-no-stencil (meaning d/s not-required, not
    not-present) config for ES 3.0, but at depth 24 of X11 we wouldn't do so.
    We can satisfy that bad requirement using a pbuffer-only visual with
    whatever other buffers the driver happens to have given us.
    I've tried to raise this as an absurd requirement with Khronos and made no
    v2: Make sure it's single sample, no depth, no stencil.  Comment typo fix
    Reviewed-by: Adam Jackson <ajax@redhat.com>


VK-GL-CTS's cts-runner adds a new configuration to the suite (41):


The cts-runner aborts when attempting to run those and, hence, doesn't complete the conformance run.

For example:

local@37d47ab783e6:~/vk-gl-cts/build/external/openglcts/modules$ MESA_GLSL_VERSION_OVERRIDE=460 MESA_GL_VERSION_OVERRIDE=4.6 ./glcts --deqp-caselist-file=gl_cts/data/mustpass/gl/khronos_mustpass/4.6.0.x/gl46-master.txt --deqp-screen-rotation=unspecified --deqp-surface-width=64 --deqp-surface-height=64 --deqp-watchdog=disable --deqp-base-seed=1 --deqp-surface-type=pbuffer --deqp-gl-config-id=41 --deqp-gl-context-type=egl --deqp-log-filename=config-gl46-master-cfg-41-run-0-width-64-height-64-seed-1.qpa --deqp-log-images=disable --deqp-log-shader-sources=disable
Writing test log into config-gl46-master-cfg-41-run-0-width-64-height-64-seed-1.qpa
dEQP Core git-ed324ca63d3a40e0b82abe4a3d155afa28fefce1 (0xed324ca6) starting..
  target implementation = 'X11 EGL'
FATAL ERROR: Got EGL_BAD_MATCH: eglCreatePbufferSurface() at egluGLContextFactory.cpp:293
Comment 1 Kenneth Graunke 2019-04-08 21:55:55 UTC
Yeah...there are some issues here.  We talked about it on March 22/23 on #dri-devel:


I came up with a couple of patches which help some of the tests:


The issue there is that we've created a double-buffered 565 config, but a number of dEQP-EGL tests want a single-buffered 565 config.  But, exposing a single-buffered config didn't work either, because some other tests assume they can get a double-buffered one.  Doing both worked better, but didn't fix everything either.

There may be additional bugs.
Comment 2 Juan A. Suarez 2019-05-23 08:55:48 UTC
Is anyone working on this? 

This bug is a blocker for 19.1.0.
Comment 3 Eric Engestrom 2019-05-23 15:13:06 UTC
(In reply to Juan A. Suarez from comment #2)
> This bug is a blocker for 19.1.0.

Is reverting dacb11a585 enough to fix the issue?

If so, I'd suggest doing that, and a new attempt can land after however long it takes.
Comment 4 Andrés Gómez García 2019-05-28 18:24:27 UTC
(In reply to Eric Engestrom from comment #3)
> (In reply to Juan A. Suarez from comment #2)
> > This bug is a blocker for 19.1.0.
> Is reverting dacb11a585 enough to fix the issue?
> If so, I'd suggest doing that, and a new attempt can land after however long
> it takes.

It should be enough. Unfortunately, I've been chasing another rabbit down the whole while testing this for quite a while :(

I'll post a MR soon-ish.
Comment 5 Andrés Gómez García 2019-05-28 22:51:55 UTC
Comment 6 Andrés Gómez García 2019-05-29 15:09:12 UTC
Clayton, in the MR the general feeling is that this shouldn't be a blocker for a release.

It is not causing prevously passing tests to fail but enabling new ones which need to be fixed but this is not a regression.

Can we drop the block and, so, the MR?
Comment 7 Clayton Craft 2019-06-06 23:11:39 UTC
I agree, this should not block 19.1. I did not completely understand what was going on here when I flagged it as blocking 19.1, but the MR discussion cleared it up for me.

I can now see that the tests which fail on 19.1-rc from this are 'not supported' when run on the last stable branches (19.0.x), which is why they came up when I was looking for regressions on the RC branch.
Comment 8 GitLab Migration User 2019-09-18 18:07:49 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/167.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.