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. 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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
