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

[Nicolai Hähnle]

On 24.10.2016 16:44, Ilia Mirkin wrote:
> On Mon, Oct 24, 2016 at 10:05 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>> On 24.10.2016 15:49, Ilia Mirkin wrote:
>>>
>>> On Mon, Oct 24, 2016 at 9:43 AM, Nicolai Hähnle <nhaehnle at 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