Bug 94668 - [IVB, BYT] Cube/3D sampling broken for INT/UINT formats
Summary: [IVB, BYT] Cube/3D sampling broken for INT/UINT formats
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Kenneth Graunke
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Blocks: i965-deqp
  Show dependency treegraph
Reported: 2016-03-23 04:19 UTC by Kenneth Graunke
Modified: 2019-03-14 08:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Kenneth Graunke 2016-03-23 04:19:30 UTC
The following tests fail on IVB and BYT:


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

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