Bug 94668

Summary:	[IVB, BYT] Cube/3D sampling broken for INT/UINT formats
Product:	Mesa	Reporter:	Kenneth Graunke <kenneth>
Component:	Drivers/DRI/i965	Assignee:	Kenneth Graunke <kenneth>
Status:	RESOLVED FIXED	QA Contact:	Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity:	normal
Priority:	medium
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	94448

Description Kenneth Graunke 2016-03-23 04:19:30 UTC

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.

Comment 1 Kenneth Graunke 2016-03-23 04:25:04 UTC

Also, HALF_BORDER doesn't exist until Gen8, so you can ignore that part of the errata.

Comment 2 Kenneth Graunke 2016-03-23 04:27:08 UTC

Also, for whatever reason, the corresponding SINT formats seem to work...at least for those tests.

Comment 3 Kenneth Graunke 2016-03-29 00:50:02 UTC

(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.

Comment 4 Kenneth Graunke 2016-03-29 03:13:43 UTC

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.

Comment 5 Kenneth Graunke 2016-03-29 06:03:33 UTC

It turns out a simple 1 line patch fixes the bug:
https://lists.freedesktop.org/archives/mesa-dev/2016-March/111084.html

Comment 6 Kenneth Graunke 2016-03-30 20:07:28 UTC

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.