On 24.10.2016 17:16, Ilia Mirkin wrote:
On Mon, Oct 24, 2016 at 11:12 AM, Nicolai Hähnle <nhaeh...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
