[Piglit] [PATCH] texture-integer-glsl130: Expect 1 for alpha in R, RG, RGB cases.

[Marek Olšák]

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.

Marek

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
>>  components."
>>
>> 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
> http://lists.freedesktop.org/mailman/listinfo/piglit
>