Comment=
# 8
on bug 89156<=
/a>
from Stefan D=C3=B6singer
I ran some more tests, it seems that the format is operating a=
t 3 bits
precision. I can produce 8 different output colors. Otherwise it seems to
follow the spec, so I don't think we're accidentally feeding the data into =
an
R3G3B2 texture.
On Windows the format operates at the expected precision - I can get any ou=
tput
data from 0x00 to 0xff.
I skimmed the GPU docs for clues what may cause this behavior but could not
find anything. The things I checked were enabling / disabling filtering, ma=
ke
sure texture address handling follows conditional NP2 texture rules, disabl=
ing
alpha blending. For the sake of testing I also tried disabling FBOs and all=
our
sRGB code.
I'm also quite sure that all 8 bits of red0 and red1 input arrive on the GP=
U. I
tested that by setting the code of each texel to 7 and then testing red0=3D=
1,
red1=3D0 and red0=3D0 and red1=3D1. In the former case this gives the resul=
t 0
(interpolation between red0 and red1), in the latter case this gives 0xfc
(MAXRED). The same works for the input values 0x80 and 0x7f.
I tested interpolation codes (e.g. red0=3D0x2, red1=3D0xa2, code 2 for each=
texel,
then try to reduce red0 or red1 by 1), and it seems that the input into the
interpolation is OK, but either the interpolation happens at a lower precis=
ion
or the output is clamped afterwards.