Bug 94196 - [HSW] border color issue with RGBA32UI
Summary: [HSW] border color issue with RGBA32UI
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Blocks: i965-deqp
  Show dependency treegraph
Reported: 2016-02-17 16:26 UTC by Ilia Mirkin
Modified: 2019-03-14 08:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

what the image should look like (677 bytes, image/png)
2016-02-17 16:27 UTC, Ilia Mirkin
what the image looks like (679 bytes, image/png)
2016-02-17 16:27 UTC, Ilia Mirkin

Description Ilia Mirkin 2016-02-17 16:26:42 UTC
RGBA32F and RGBA32I variants of the test work fine. Very odd issue. See the results.

This is hit by dEQP-GLES31.functional.texture.border_clamp.formats.rgba32ui.nearest_size_pot which needs my recent patches to run, in addition to some other things. If you're interested in running this yourself, let me know and I can provide the various instructions.

Attached are the error and expected images. Note that it seems like the border color "eventually" works out, but near the image it's white.
Comment 1 Ilia Mirkin 2016-02-17 16:27:21 UTC
Created attachment 121815 [details]
what the image should look like
Comment 2 Ilia Mirkin 2016-02-17 16:27:44 UTC
Created attachment 121816 [details]
what the image looks like
Comment 3 Ilia Mirkin 2016-02-17 16:32:18 UTC
Should be noted that the broken one:

Border color is (1288490240, 3006477056, 858993472, 2147483648)

While there's a working one in the log:

Border color is (3865470464, 858993472, 1717986944, 2576980480)

Note sure if it hates the 0x80000000 value. Or if it's based on the position of the rendered image. (The one that passes is in the upper-right corner.) The image itself is 32x16.
Comment 4 Kenneth Graunke 2016-05-31 08:46:17 UTC
This is pretty strange.  Overriding the texturing format from R32G32B32A32_UINT to R32G32B32A32_SINT doesn't change the results at all - it still fails in the same manner.  Changing it to FLOAT works though.

Which is weird, since the rgba32i test works...
Comment 5 Tapani Pälli 2018-08-10 07:43:19 UTC
This test is passing on my HSW, has this bug been fixed?
Comment 6 Mark Janes 2018-08-10 15:01:40 UTC
i965 CI shows that this test was fixed for HSW by deqp:

Comment 7 Mark Janes 2018-08-10 15:02:38 UTC
FWIW, here is the commit message that was merged:

Author:     Nicolas Capens <capn@google.com>
AuthorDate: Mon Jan 8 16:49:05 2018 -0500
Fix using representable texture channel ranges.

A value of 4294967295 (2^32 - 1) is not exactly representable in
IEEE-754 single-precision floating-point format, and so it gets rounded
to the next representable value, which is 4294967296. However, this
value can't be cast to an unsigned 32-bit integer without overflowing.

GLSL does not define what happens on overflow, and IEEE-754 defines it
as an exception but GLSL forbids exceptions. Hence some implementations
may produce unexpected results. dEQP assumed clamping to the largest
representable integer.

This change fixes that false assumption by reducing the range to values
representable in both float and integer formats.

Note that 32-bit integer formats can still hold values slightly larger
than these ranges. So while previously the floating-point ranges were
too large to represent integer values, they are now too small. This
can't be fixed without separating the integer format tests and only
using integer values to represent their ranges. This doesn't appear
necessary for the time being since the tests that use these floating-
point ranges have large 12/256 tolerances for the output color.

Google bug: 70910885
Component: Framework

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.