[Piglit] [PATCH] texture-integer-glsl130: Expect 1 for alpha in R, RG, RGB cases.
maraeo at gmail.com
Thu Nov 22 05:57:16 PST 2012
The test fails because it's wrong. The expected integer alpha is 1,
but the "bias" is a large negative value, therefore (a - bias) is
always <= 0, so the test always fails.
On Mon, Nov 19, 2012 at 5:41 PM, Eric Anholt <eric at anholt.net> wrote:
> Kenneth Graunke <kenneth at whitecape.org> writes:
>> From the GL 3.0 specification, page 162:
>> "Final Expansion to RGBA
>> This step is performed only for non-depth component groups. Each group
>> is converted to a group of 4 elements as follows: if a group does not
>> contain an A element, then A is added and set to 1 for integer
>> components or 1.0 for floating point components. If any of R, G, or B
>> is missing from the group, each missing element is added and assigned a
>> value of 0 for integer components or 0.0 for floating point
>> In other words, alpha should always be 1 when sampling from textures
>> whose format has less than 4 components.
>> tests/spec/ext_texture_integer/texture-integer-glsl130.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>> I think this is correct, but I'd really appreciate a sanity check.
>> This completely breaks the test on i965 (it was previously intermittent), but
>> I'm fairly certain that's a bug. Reading the hardware docs (the "Sampler
>> Output Channel Mapping" section), it should promote R to (R, 0, 0, 1) and RG
>> to (R, G, 0, 1). It just doesn't seem to be for some reason. :/
> While I think it's a correct change, I think the citation is wrong --
> page 160 is about pixel rectangle transfers, and I don't think those
> rules apply to texture sampling. Page 221, table 3.23 does say alpha
> gets set to 1 in the texture sampling result for formats that don't
> mention alpha.
> Piglit mailing list
> Piglit at lists.freedesktop.org
More information about the Piglit