The following tests fail on IVB and BYT: dEQP-GLES3.functional.shaders.texture_functions.texturegrad.usamplercube_vertex dEQP-GLES3.functional.shaders.texture_functions.texturegrad.usamplercube_fragment dEQP-GLES3.functional.shaders.texture_functions.texturelod.usamplercube_vertex dEQP-GLES3.functional.shaders.texture_functions.texturelod.usamplercube_fragment This appears to be because the i965 driver fails to work around a hardware bug. From the Ivybridge PRM, Volume 4 Part 1, pages 128-130: "If the Surface Format of the associated surface is UINT or SINT, the Surface Type cannot be SURFTYPE_3D or SURFTYPE_CUBE and Address Control Mode cannot be CLAMP_BORDER or HALF_BORDER." This appears to apply to the sample, sample+killpix, sample_b, sample_l, and sample_d messages. According to Intel internal documentation, this errata applies to IVB and HSW. Nobody ever mentions BYT, but the IVB comment likely applies. However, the above tests all pass on my Haswell, so I don't think it applies there.
Also, HALF_BORDER doesn't exist until Gen8, so you can ignore that part of the errata.
Also, for whatever reason, the corresponding SINT formats seem to work...at least for those tests.
(In reply to Kenneth Graunke from comment #2) > Also, for whatever reason, the corresponding SINT formats seem to work...at > least for those tests. It turns out a lot more tests were failing than I realized - about 40 or so. I've fixed most of them via format hacks, but I'm thinking of trying a cube-to-2DArray lowering pass instead.
For more utter comedy, the Sandybridge documentation says that sampler messages can't handle INT/UINT formats at all. But we've been exposing integer textures there for years and it appears to be working fine. Also, I found the 46 failing cube tests, and ran the sampler3D equivalent for each. All of them passed. So I think 3D is working fine. I noticed in the image results that most of the failing tests seemed to have a single broken pixel in the bottom right of the image. This made me think about wrap modes. It appears that overriding the wrap modes from CUBE to CLAMP when using integer formats also fixes the tests. It seems reasonable, since there's no linear filtering for integer formats. But I don't see any documentation indicating this should be necessary, and it doesn't appear to be necessary on Haswell and later hardware.
It turns out a simple 1 line patch fixes the bug: https://lists.freedesktop.org/archives/mesa-dev/2016-March/111084.html
This is "fixed" by: commit d4a5a61d445e683c20de00c1febe847b4c2db910 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Mon Mar 28 20:07:13 2016 -0700 i965: Don't use CUBE wrap modes for integer formats on IVB/BYT. There is no linear filtering for integer formats, so we should always be using CLAMP_TO_EDGE mode. Fixes 46 dEQP cases on Ivybridge (which were likely broken by commit 0faf26e6a0a34c3544644852802484f2404cc83e). This workaround doesn't appear to be necessary on any other hardware; I haven't found any documentation mentioning errata in this area. v2: Only apply on Ivybridge/Baytrail to avoid regressing GLES3.1 tests. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> [v1] This leaves gather4 on cubes doing the wrong thing at edges (see bug 94621), but there are no tests for that until ES 3.1 is enabled. So I'm punting on the problem for now. There's no real good solution for it, but there are some hacks that could be done to alleviate the problem in many cases.
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.