anv: advertise 8 subtexel/mipmap precision bits
authorJuan A. Suarez Romero <jasuarez@igalia.com>
Tue, 9 Apr 2019 15:28:42 +0000 (15:28 +0000)
committerJuan A. Suarez Romero <jasuarez@igalia.com>
Tue, 9 Apr 2019 15:28:42 +0000 (15:28 +0000)
commitec7a33af58dbf421c58dfcc65c680e9c2f1ce09a
tree65f3682c8c7fdb27c99d3f341dc3a63ff3d330bb
parentd507bcdcf26b417dea201090165af651253b6b11
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 <jason@jlekstrand.net>
CC: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
src/intel/vulkan/anv_device.c