[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