Bug 109655

Thank you for reporting it, I will get a look.

I just tried to reproduce the failure on HSW and the test passes. Also, I hadn't seen any failures on jenkins when I tested the branch some days ago.

I have the extension enabled, GLES v. 3.1, and I run the test like that:
./glcts -n dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer

and I see this output:
Test run totals:
  Passed:        1/1 (100.0%)

Is this the correct way to reproduce it? Should I do something different?

Thank you in advance,
Eleni

Apologies, I didn't see at once that the failure comes from the 32-bit build :)
I'll take a look again.

I've built mesa (-m32) and ran the test but the test you mentioned seems to pass locally: 

./glcts -n dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer

Test case 'dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer'..
  Pass (Pass)

I also ran the dEQP-GLES31.functional.copy_image.* tests without failures:

Test run totals:
Passed:        8363/12395 (67.5%)
Failed:        0/12395 (0.0%)
Not supported: 4032/12395 (32.5%)
Warnings:      0/12395 (0.0%)

Do you still see the failures?
Any advice on how I could reproduce it?

I'm not sure what to tell you...  I just built deqp/mesa/drm in both 32 and 64 bit variants, into side-by-side directories on the same hsw machine:

64bit:
/tmp/build_root/m64/opt/deqp/modules/gles31$ MESA_GLES_VERSION_OVERRIDE=3.1 INTEL_PRECISE_TRIG=1 vblank_mode=0 LIBGL_DRIVERS_PATH=/tmp/build_root/m64/lib/dri:/tmp/build_root/m64/lib64/dri:/tmp/build_root/m64/lib/x86_64-linux-gnu/dri:/usr/lib/dri:/usr/lib64/dri:/usr/lib/x86_64-linux-gnu/dri LD_LIBRARY_PATH=/tmp/build_root/m64/lib:/tmp/build_root/m64/lib64:/tmp/build_root/m64/lib/x86_64-linux-gnu:/usr/lib:/usr/lib64:/usr/lib/x86_64-linux-gnu DISPLAY=:0  ./deqp-gles31 -n dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer
Writing test log into TestResults.qpa
dEQP Core git-d377f3be7af942c3c0181b8ba9a35c32f39c0974 (0xd377f3be) starting..
  target implementation = 'X11 EGL'
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.

Test case 'dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer'..
  Pass (Pass)

DONE!

Test run totals:
  Passed:        1/1 (100.0%)
  Failed:        0/1 (0.0%)
  Not supported: 0/1 (0.0%)
  Warnings:      0/1 (0.0%)

------------------------------------------------------------------
32-bit:
/tmp/build_root/m32/opt/deqp/modules/gles31$ MESA_GLES_VERSION_OVERRIDE=3.1 INTEL_PRECISE_TRIG=1 vblank_mode=0 LIBGL_DRIVERS_PATH=/tmp/build_root/m32/lib/dri:/tmp/build_root/m32/lib/i386-linux-gnu/dri:/usr/lib/dri:/usr/lib/i386-linux-gnu/dri LD_LIBRARY_PATH=/tmp/build_root/m32/lib:/tmp/build_root/m32/lib/i386-linux-gnu:/usr/lib:/usr/lib/i386-linux-gnu DISPLAY=:0  ./deqp-gles31 -n dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer
Writing test log into TestResults.qpa
dEQP Core git-d377f3be7af942c3c0181b8ba9a35c32f39c0974 (0xd377f3be) starting..
  target implementation = 'X11 EGL'
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.

Test case 'dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer'..
  Fail (Image comparison failed.)

DONE!

Test run totals:
  Passed:        0/1 (0.0%)
  Failed:        1/1 (100.0%)
  Not supported: 0/1 (0.0%)
  Warnings:      0/1 (0.0%)

You could probably reproduce the build configuration by running i965 CI automation locally.  Let me know if that is something you want to do.

Sure, I'd like to, if you could share some instructions, that would be great.

I tried again using mesa/drm built with -m32 in CC, CXX, CFLAGS, CXXFLAGS in a 32bit schroot, I've built the cts with target x11_egl and I used the same env variables you used:

INTEL_PRECISE_TRIG=1 vblank_mode=0
MESA_GLES_VERSION_OVEERRIDE=3.1

Then I ran:
$ ./deqp-gles31 -n dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer
Writing test log into TestResults.qpa
dEQP Core git-306b2d31946519d84f9960ecbc661d6df3ec2d08 (0x306b2d31) starting..
  target implementation = 'X11 EGL'
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.

Test case 'dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer'..
  Pass (Pass)

DONE!

Test run totals:
  Passed:        1/1 (100.0%)
  Failed:        0/1 (0.0%)
  Not supported: 0/1 (0.0%)
  Warnings:      0/1 (0.0%)


There must be something different in the configuration I am missing when I run the tests. :/

Hi guys!
I've tried to run tests with both variants (32 and 64 bit) - both tests are successfully passed.
I've tested on Haswell (Intel® HD Graphics 4600) on Manjaro with 4.20.10 Kernel.

Mark, maybe you have some additional preconditionals or smth else?

Could it be one of those annoying 32bit kernel bug that got fixed in i915?

Mark: What version of the kernel are you running?

4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 GNU/Linux

I cannot reproduce either. Also crosscompiling, using a docker i386 image in a x86_64 host

This is the host:

$ uname -srvmo
Linux 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17) x86_64 GNU/Linux

My host:
4.18.0-2-amd64 #1 SMP Debian 4.18.10-1 (2018-09-30) i686 GNU/Linux

GPU: Haswell Desktop x86/MMX/SSE2/Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)

if helps.

(In reply to Andrés Gómez García from comment #10)
> I cannot reproduce either. Also crosscompiling, using a docker i386 image in
> a x86_64 host
> 
> This is the host:
> 
> $ uname -srvmo
> Linux 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17) x86_64 GNU/Linux

Ugly bug :(

I've created another docker i386 image *without crosscompiling* and I'm now able to reproduce running on the same host machine with the same x86_64 kernel.

You can try to reproduce just with this command (notice that the image is ~9G so it will take some time to download):

$ docker run --privileged --rm -t -e DISPLAY=unix:0.0 -v /tmp/.X11-unix:/tmp/.X11-unix igalia/mesa:i386-vk-gl-cts /bin/bash -c "cd ~/VK-GL-CTS/_build/external/openglcts/modules; MESA_GLES_VERSION_OVERRIDE=3.1 INTEL_PRECISE_TRIG=1 vblank_mode=0 ./glcts --deqp-case=dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer"

Sorry I didn't have time to look into this more yesterday, but I'm glad that you were finally able to reproduce it.

(In reply to Andrés Gómez García from comment #12)

[...]

> $ docker run --privileged --rm -t -e DISPLAY=unix:0.0 -v
> /tmp/.X11-unix:/tmp/.X11-unix igalia/mesa:i386-vk-gl-cts /bin/bash -c "cd
> ~/VK-GL-CTS/_build/external/openglcts/modules;
> MESA_GLES_VERSION_OVERRIDE=3.1 INTEL_PRECISE_TRIG=1 vblank_mode=0 ./glcts
> --deqp-case=dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.
> rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer"

FWIW, taking this image and testing in KBL and SKL I get the same result so it may not be limited just to HSW but just a pre-existent problem that is exposed now in HSW as the extension has been enabled (?). Maybe the problem is in the test.

Just to check again, I added into that image a crosscompiled mesa and VK-GL-CTS and I can also reproduce.

You can try to reproduce just with this command:

$ docker run --privileged --rm -t -e DISPLAY=unix:0.0 -v /tmp/.X11-unix:/tmp/.X11-unix igalia/mesa:i386-cross-vk-gl-cts /bin/bash -c "cd ~/VK-GL-CTS/_build_cross/external/openglcts/modules; MESA_GLES_VERSION_OVERRIDE=3.1 INTEL_PRECISE_TRIG=1 vblank_mode=0 LIBGL_DRIVERS_PATH=/root/mesa-install_cross/lib/i386-linux-gnu/dri LD_LIBRARY_PATH=/root/mesa-install_cross/lib/i386-linux-gnu/ ./glcts --deqp-case=dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba8_etc2_eac_rgba32ui.texture2d_to_renderbuffer"

These tests were disabled due to 103746.  Sadly, they were not re-enabled when that bug was closed.

I'll re-enable those tests in the i965 CI to see what the current results are.

I can confirm that this failure occurs on SKL and later.  My initial write-up was incorrect because the tests were disabled.

I agree that it is possible that we are looking at a test bug.  From the Google program office: 

  "The deadline for raising issues with the mustpass tests is *March 25*."

(In reply to Mark Janes from comment #9)
> 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 GNU/Linux

As far as I can tell 4.19.12 should have all the fixes we need, so it seems to rule out the kernel.

removing regression tag, because this test failed on other platforms before Eleni enabled it on gen 7.5 and earlier.

Eleni: perhaps the fastest way to identify this as a bug in the test suite would be to test on non-intel hardware.

Do you have any that could be used for this?

AFAIK we have some nvidia machines, I will try to set up an i386 environment in one of them and see if I can reproduce it. If it's reproducible then it's definitely in the test, but if not... I think that we can't say for sure it's on mesa.. :) I'll get a look.

nVIDIA fails or doesn't support the whole "functional.copy_image.mixed" subset of tests, no matter i386 or X86_64:

--



$ ./glcts --deqp-case=dEQP-GLES31.functional.copy_image.mixed.*
Writing test log into TestResults.qpa
dEQP Core git-3a471d260788b3465d714707e1b5c5bd4bc9591b (0x3a471d26) starting..
  target implementation = 'X11 EGL'

Test case 'dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.rgba32f_rgba8_etc2_eac.texture2d_to_texture2d'..
  Fail (glCopyImageSubData failed.: glGetError() returned GL_INVALID_OPERATION at es31fCopyImageTests.cpp:1120)

[...]

Test case 'dEQP-GLES31.functional.copy_image.mixed.viewclass_128_bits_mixed.srgb8_alpha8_astc_12x12_khr_rgba32i.texture3d_to_texture2d'..
  NotSupported (TEXTURE_3D target requires HDR astc support. at es31fCopyImageTests.cpp:1905)

[...]

Test case 'dEQP-GLES31.functional.copy_image.mixed.viewclass_64_bits_mixed.signed_r11_eac_rg32i.cubemap_to_renderbuffer'..
  Fail (glCopyImageSubData failed.: glGetError() returned GL_INVALID_OPERATION at es31fCopyImageTests.cpp:1120)

DONE!

Test run totals:
  Passed:        0/3584 (0.0%)
  Failed:        2800/3584 (78.1%)
  Not supported: 784/3584 (21.9%)
  Warnings:      0/3584 (0.0%)

--

$ glxinfo | grep OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 1070/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 418.43
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 418.43
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 418.43
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

--

$ glxinfo | grep OES_copy_image
    GL_OES_compressed_ETC1_RGB8_texture, GL_OES_copy_image, GL_OES_depth24, 

--

$ glxinfo | grep ARB_ES3_compatibility
    GL_ARB_ES3_2_compatibility, GL_ARB_ES3_compatibility, 
    GL_ARB_ES3_2_compatibility, GL_ARB_ES3_compatibility,

radeonsi passes the test(s) in i386 and X86_64.

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