Author: Eric Anholt <firstname.lastname@example.org>
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 <email@example.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.
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
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.
Is anyone working on this?
This bug is a blocker for 19.1.0.
(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.
(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.
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?
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.