[Mesa-dev] [PATCH 2/2] glsl: Handle bits=32 case in bitfieldInsert/bitfieldExtract.

[Matt Turner]

On Wed, Dec 30, 2015 at 8:55 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 30.12.2015 um 21:26 schrieb Matt Turner:
>> The OpenGL specifications for these functions say:
>>
>>    The result will be undefined if <offset> or <bits> is negative, or if
>>    the sum of <offset> and <bits> is greater than the number of bits
>>    used to store the operand.
>>
>> Therefore passing bits=32, offset=0 is legal and defined in GLSL.
>>
>> But the earlier DX11/SM5 bfi/ibfe/ubfe opcodes are specified to accept a
>> bitfield width ranging from 0-31. As such, Intel and AMD instructions
>> read only the low 5 bits of the width operand, making them not compliant
>> with the GLSL spec, so we have to special case the bits=32 case.
>>
>> Checking that offset=0 is not necessary, since for any other value,
>> <offset> + <bits> will be greater than 32, which is specified as
>> generating an undefined result.
> What about offset=32, bits=0, will that work?
>
>>
>> Fixes:
>>    ES31-CTS.shader_bitfield_operation.bitfieldInsert.uint_2
>>    ES31-CTS.shader_bitfield_operation.bitfieldInsert.uvec4_3
>>    ES31-CTS.shader_bitfield_operation.bitfieldExtract.uvec3_0
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92595
>> ---
>> Yuck. Suggestions welcome.
> Do blob drivers do that correctly? Otherwise make it a spec bug?
> (Albeit I can see from a theoretical point of view why those 0/32 cases
> make sense so it probably really is intentional.)

Intentional might be an overstatement (given that hardware from major
vendors couldn't implement it with the intended instructions...), but
I don't think it's a spec bug and I really don't think it's fixable
there since it's tested in the ES 3.1 conformance suite.