summaryrefslogtreecommitdiffstats
path: root/bin
diff options
context:
space:
mode:
authorJuan A. Suarez Romero <[email protected]>2019-04-09 15:28:42 +0000
committerJuan A. Suarez Romero <[email protected]>2019-04-09 15:28:42 +0000
commitec7a33af58dbf421c58dfcc65c680e9c2f1ce09a (patch)
tree65f3682c8c7fdb27c99d3f341dc3a63ff3d330bb /bin
parentd507bcdcf26b417dea201090165af651253b6b11 (diff)
anv: advertise 8 subtexel/mipmap precision bits
So far ANV was advertising 4 bits for both subTexelPrecisionBits and mipmapPrecisionBits. But these values were not actually verified. But it seems the right value is actually 8 bits for both cases. Unfortunately Intel PRM does not clarify how many bits the hardware use. For the mipmap case, there is the following reference in PRM Volume 6 (3D Media GPGPU), specifically in LOD Computation Pseudocode: ``` Bias: S4.8 MinLod: U4.8 MaxLod: U4.8 Base: U4.1 MIPCnt: U4 SurfMinLod: U4.8 ResMinLod: U4.8 `` We have other clues, though: - On one side, dEQP-VK.texture.explicit_lod.* tests fail when using 4 bits, but work when using 8 bits. These tests try to mimic the expected behaviour as much real as possible, and they use the reported subTexelPrecisionBits and mipmapPrecisionBits reported to get this. - On the other side, the equivalent driver for Windows is reporting 8 bits for both elements. Not sure if they got to verify it from the PRM or from a diffent source. CC: Jason Ekstrand <[email protected]> CC: Lionel Landwerlin <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
Diffstat (limited to 'bin')
0 files changed, 0 insertions, 0 deletions