[Gen7-8] Integer and snorm texture views can be incorrect
Submitted by Nanley Chery
Assigned to Intel 3D Bugs Mailing List
On BDW and earlier, fast-clear colors are limited to 0 and a format-dependent 1 per-channel. For integer textures, the 1 equals 0x1 and for float textures the 1 equals 1.0f (0x3f80000). Due to the clear color value of 1 being interpreted differently for different formats, it should not be possible to use it without introducing resolves.
i965 currently allows fast-clearing a float texture to 1 but doesn't introduce a resolve when accessing the texture as an integer.
We can demonstrate the problem this causes by doing the following:
- Fast clear an R32F texture to 1.0. For the purpose of this example, we make it 64x64px.
- Create an R32UINT texture view from the R32F.
- Render to the first row of the R32UINT. This will cause the HW to write out the fast clear color in the parts of the cacheline pairs not written to. Each CL Pair has a dimension of 8x4px.
- Read back the texture as R32UINT.
- Observe that the following 3 rows are equal to 1 instead of the 0x3f800000 it was cleared to in step 1.
We need write a bug to exercise this issue, and then fix it. The piglit test at: tests/spec/arb_texture_view/rendering-r32ui.c looks like a good place to start.