On 24.10.2016 16:44, Ilia Mirkin wrote:
On Mon, Oct 24, 2016 at 10:05 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
On 24.10.2016 15:49, Ilia Mirkin wrote:
On Mon, Oct 24, 2016 at 9:43 AM, Nicolai Hähnle <nhaeh...@gmail.com>
wrote:
On 24.10.2016 15:38, Nicolai Hähnle wrote:
On 24.10.2016 15:34, Ilia Mirkin wrote:
These work properly on nvc0. I'd rather you work around it in your
backend.
That's not a good solution because of how the opcodes are defined. How
about TGSI_OPCODE_{BFI,[UI]BFE}_GLSL and an associated pipe cap that
gets enabled for nvc0?
Or we can declare that the semantics of BFI/BFE should just be in line
with
what GLSL wants. I don't know if there are other state trackers that rely
on
it, it seems that you were actually the one who introduced the wording in
tgsi.rst...
Yeah, as part of the ARB_gpu_shader5 bringup. At the time, I believe I
specified them as the DX11 thing since I assumed it was identical to
the GLSL. I've since learned that not to be the case.
If you want to introduce new ops/caps to differentiate the GLSL way
and the DX11 way, that's fine by me. (And I'm not picky about which op
gets the original name...)
Okay. The question is whether anybody actually needs the DX11 way. Since
there's only a nine and not an eleven, I kind of suspect the answer is 'no',
and then there's no need for a cap.
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.
I might also add that I added logic to the pack/unpack helpers to make
use of BFE/BFI in various cases. I'm pretty sure they don't need the
workaround logic either.
Yeah, those are probably fine.
Nicolai
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
