diff options
author | Juan A. Suarez Romero <[email protected]> | 2019-04-09 15:28:42 +0000 |
---|---|---|
committer | Juan A. Suarez Romero <[email protected]> | 2019-04-09 15:28:42 +0000 |
commit | ec7a33af58dbf421c58dfcc65c680e9c2f1ce09a (patch) | |
tree | 65f3682c8c7fdb27c99d3f341dc3a63ff3d330bb /bin | |
parent | d507bcdcf26b417dea201090165af651253b6b11 (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