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.
-- 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.