Bug 110357

Summary:	[BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration
Product:	Mesa	Reporter:	Andrés Gómez García <agomez>
Component:	EGL	Assignee:	mesa-dev
Status:	RESOLVED MOVED	QA Contact:	mesa-dev
Severity:	normal
Priority:	medium	CC:	agoldmints, agomez, clayton.a.craft, eric, fdo-bugs, gpoo+bfdo, intel-3d-bugs, jasuarez, kenneth
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	102590

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

After:

--

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
    progress.
    
    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):

config-gl46-gtf-master-cfg-41-run-22-width-64-height-64-seed-1.qpa
config-gl46-gtf-master-cfg-41-run-23-width-113-height-47-seed-2.qpa
config-gl46-master-cfg-41-run-0-width-64-height-64-seed-1.qpa
config-gl46-master-cfg-41-run-1-width-113-height-47-seed-2.qpa

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
Killed

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:

https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2019-03-23

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

https://gitlab.freedesktop.org/kwg/mesa/tree/pb565-two-configs
https://gitlab.freedesktop.org/kwg/mesa/tree/pb565-singleonly

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

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/963

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.