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
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.
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.
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/963
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.
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.