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: 1. Fast clear an R32F texture to 1.0. For the purpose of this example, we make it 64x64px. 2. Create an R32UINT texture view from the R32F. 3. 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. 4. Read back the texture as R32UINT. 5. 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.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1711.
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.