System Environment: -------------------------- Arch: i386 Platform: Sandybridge Libdrm: (master)2.4.34-2-g481234f2909c0506962a2f42da862da6a9b13fd8 Mesa: (master)0f6a3a7de3b56a383061635016cdb10f0229bf02 Xserver: (master)xorg-server-1.12.0-189-g9bc53d8cb04af2be3feeebb1b10774c2d599a76b Xf86_video_intel: (master)2.19.0-79-gfb9da4cb9e12ca733c31879b8b37906f361a8c35 Libva: (staging)f12f80371fb534e6bbf248586b3c17c298a31f4e Libva_intel_driver:(staging)82fa52510a37ab645daaa3bb7091ff5096a20d0b Kernel_unstable: (drm-intel-next-queued)c8d4bb54c11c66610aaf8829acff6aa0506c7c29 Bug detailed description: ----------------------------- It fails on ivybridge and sandybridge with mesa master branch.It doesn't happen on mesa 8.0 branch. Following Ogles1conform cases also fail and have same bisect result: mustpass.c mstack.c xformmix.c vorder.c xform.c xformn.c xformvp.c bclear.c bcorner.c bcolor.c colramp.c mask.c scissor.c apfunc.c spclear.c spcorner.c spop.c spfunc.c zbclear.c pntrast.c linerast.c trirast.c tritile.c polycull.c l_al.c l_am.c l_as.c l_ac.c l_ap.c l_dl.c l_dm.c l_dmn.c l_dmp.c l_em.c l_se.c l_sen.c l_sl.c l_sm.c l_sn.c l_sp.c l_sep.c l_sed.c fogexp.c foglin.c texdecal.c miplin.c texedge.c packpix.c multitex.c texpalet.c xformw.c clip.c readfmt.c copytex.c pntsprt.c userclip.c bufobj.c bisect show:a3967ff441e95289a0a33a4a02ab7cd15b010a51 is the first bad commit. commit a3967ff441e95289a0a33a4a02ab7cd15b010a51 Author: Eric Anholt <eric@anholt.net> AuthorDate: Fri May 18 11:53:29 2012 -0700 Commit: Eric Anholt <eric@anholt.net> CommitDate: Wed May 23 10:18:26 2012 -0700 i965: We always have GLSL, so always use it for tri clears. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This should be the fix: commit ff3eef1affd0d3b56d4ce689947947be97c5d0f6 Author: Oliver McFadden <oliver.mcfadden@linux.intel.com> Date: Sat May 26 10:13:07 2012 +0300 mesa: don't compile integer clear shaders for unsupported APIs
Following cases still fail on ivybridge and sandybridge,and following cases also fail on ironlake with mesa master branch. mustpass.c xformmix.c vorder.c bclear.c mask.c scissor.c apfunc.c spclear.c spcorner.c spop.c spfunc.c zbclear.c linerast.c trirast.c tritile.c polycull.c packpix.c xformw.c clip.c userclip.c bufobj.c
I can confirm this - switching to _mesa_meta_Clear instead of _mesa_meta_glsl_Clear fixes the ES tests. Still need to investigate why it's broken.
The problem is simple enough. In api_validate.c, on line 120, we have: #if FEATURE_ES1 case API_OPENGLES: /* For OpenGL ES, only draw if we have vertex positions */ if (!ctx->Array.ArrayObj->VertexAttrib[VERT_ATTRIB_POS].Enabled) return GL_FALSE; break; #endif This rejects any drawing from _mesa_meta_glsl_Clear(), as it doesn't use VERT_ATTRIB_POS...it uses a custom attribute. Simply deleting the code and letting it fall through to the API_OPENGL case works. This may even be the right thing to do. If there's a shader program (we're using GLSL internally), the API_OPENGL case does the right thing. If not, it checks if VERT_ATTRIB_POS is enabled (the same as the ES1 check) or a generic attribute is enabled (which don't exist in ES1, so it should be safe). The only trouble there, as far as I can tell, is making it compile if FEATURE_ES1 && !FEATURE_GL. Punting it back to Eric to decide what to do, but hopefully the analysis should save him some time.
Fixed on commit 34665381713249c29b7da5028396222dfea477c2.
Verified .Fixed.
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.