System Environment: -------------------------- Arch: x86_64 Platform: Ivybridge Libdrm: (master)libdrm-2.4.41-4-g9dc0072e8d5a47fb0b2ada50fb897cb2c740bb40 Mesa: (master)51b64ce47bd8ed5da185f4fb76e7a3d3238b72c2 Xserver:(master)xorg-server-1.13.99.901-37-g7fe5e6dfa5c1e71d8b7540b28c1d508687a2fbee Xf86_video_intel:(master)2.20.19-32-g8ffb3f50b3b4601401da76e2848e059ab63231f4 Cairo: (master)c986a7310bb06582b7d8a566d5f007ba4e5e75bf Libva: (staging)21649988d6b532cc96f633db017d1e4369f640e9 Libva_intel_driver:(staging)b7cb38772e6f73d3c1b3465e0bc6c0009c2f5634 Kernel: (drm-intel-nightly) 46e5ccbec5bc5f20e5b2733ba2e8a5b7e43fcf8f Bug detailed description: ------------------------- It fails on ivybridge with mesa master branch, It doesn't happen on 9.0 branch. Following cases also fail and have some bisect commit: gles2_shaders_for_33 gles2_shaders_for_if_break gles2_shaders_for_if_continue gles2_shaders_if_builtin_discard Bisect shows: 1d0e8c109c34ca31b5a00d1561f4fbfe53adf8c0 is the first bad commit. commit 1d0e8c109c34ca31b5a00d1561f4fbfe53adf8c0 Author: Ian Romanick <ian.d.romanick@intel.com> AuthorDate: Wed Aug 8 15:25:00 2012 -0700 Commit: Ian Romanick <ian.d.romanick@intel.com> CommitDate: Fri Jan 25 08:30:40 2013 -0500 mesa/es3: Enable ES 3.0 API and shading language version v2: Add ARB_internalformat_query to the list of required extensions. v3: Add OES_depth_texture_cube_map to the list of required extensions. output: EGL_VERSION = 1.4 (DRI2) Probe at (62,62) Expected: 0.190000 0.000000 0.000000 Observed: 0.996078 0.513725 0.058824 PIGLIT: {'result': 'fail' } Reproduce steps: ---------------- 1. xinit 2. ./gles2_shader_runner -auto tests/gles2/18_else_case.shader_test
It also happens on haswell.
I can't find any of these tests in piglit.
Created attachment 73805 [details] test case
I believe this is a piglit bug, and I will submit a patch shortly. The OpenGL ES 3.0 spec says: "Only two combinations of format and type are accepted. The first is format RGBA and type UNSIGNED BYTE. The second is an implementation-chosen format from among those defined in table 3.4, excluding formats LUMINANCE and LUMINANCE ALPHA." The test case does "relative probe rgb", which piglit implements using glReadPixels(GL_RGB). Our OpenGL ES 2.0 path *incorrectly* allow this, but our OpenGL ES 3.0 path does not. As soon as the ES version switched to 3, the driver started using the stricter checks, and the glReadPixels call failed. I believe two things should be done to fix this: 1. Modify the piglit probe code to always use GL_RGBA or GL_RGBA_INTEGER in ES mode. If the probe is RGB, the alpha component can just be ignored. 2. Unify the ES2 and ES3 ReadPixels error check paths in Mesa a bit more so that the ES2 path more closely follows the spec. If Tom and Jordan think this is reasonable, I'll change the description of this bug and file a separate piglit bug.
It still fails on latest master branch(commit: 0486d503209cf375ae77456)
Ian, have you followed up with the piglit bug?
Ian?
Created attachment 110336 [details] [review] Update a case in piglit-gles2 to follow the spec of ES3 This case is belong to project Piglit-gles2(not piglit), which is porting from piglit, and used to test gles. this project is not followed the upgrade from OpenGL ES2.0 to OpenGL ES 3.0,so this case is failed. Ian's comment at 4# is the root cause:"As soon as the ES version switched to 3, the driver started using the stricter checks, and the glReadPixels call failed." I just modify the project "piglit-gles2", to follow the upgrade from OpenGL ES2.0 to OpenGL ES 3.0.Attachment is the patch. Than the case is pass. Since this project is abandon now, I think this bug can be closed. For the two things which was mentioned by Ian: [Ian]1. Modify the piglit probe code to always use GL_RGBA or GL_RGBA_INTEGER in ES mode. If the probe is RGB, the alpha component can just be ignored. [Shuo]I checked the source code of Piglit, the related part of Piglit has big change, and if there is any new bug, we should open a new one. [Ian]2. Unify the ES2 and ES3 ReadPixels error check paths in Mesa a bit more so that the ES2 path more closely follows the spec. [Shuo]Not sure about this one, but from this case I can see, we wanted to go through ES2 path(which is not contained so much stricter checks), but this case still failed.So I think, at least the error check of this part, ES2 and ES3 is unified.
This case is pass after the case is updated from ES2-> ES3, so close it.
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.