[Mesa-dev] [PATCH] st/glsl_to_tgsi: fix mismatch between TGSI BFI/BFE and GLSL

Nicolai Hähnle nhaehnle at gmail.com
Mon Oct 24 16:11:14 UTC 2016


On 24.10.2016 17:16, Ilia Mirkin wrote:
> On Mon, Oct 24, 2016 at 11:12 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>> On 24.10.2016 16:44, Ilia Mirkin wrote:
>>> In any case, the GLSL way is backwards-compatible with the DX11 way.
>>> It just specifies some unspecified situations.
>>
>> No, it isn't -- that's the whole problem :)
>>
>> Both GLSL and SM5 specify clearly what should happen for the offset=0,
>> bits=32 case, but they disagree.
>
> Oh. Interesting. Do we have tests for that? (Do they fail on nvc0?
> Pretty sure they were passing last I checked...)
>
> I find this very surprising BTW - please double-check.

For SM5: 
https://msdn.microsoft.com/en-us/library/windows/desktop/hh446837(v=vs.85).aspx 
is pretty clear that only the 5 LSBs matter, i.e. bits=32 should be the 
same as bits=0.

For GLSL, the quote is:

   Extracts bits [offset, offset + bits - 1] from value,
   returning them in the least significant bits of the result.
   [...]
   If bits is zero, the result will be zero. 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.

None of this would be a problem if the spec said "greater than or equal 
to" instead.

We have piglit tests for that, which I realize now I forgot to mention 
in the commit message: 
arb_gpu_shader5/execution/built-in-functions/{fs,vs}-bitfield{extract,insert}.

There's also a GL CTS test that checks for this.

Cheers,
Nicolai


More information about the mesa-dev mailing list