[Mesa-dev] [PATCH 1/3] gallium: add explicit return type to texture opcodes

[Marek Olšák]

On Wed, Aug 24, 2016 at 3:44 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 24.08.2016 um 11:26 schrieb Marek Olšák:
>> On Wed, Aug 24, 2016 at 2:10 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>>> Am 22.08.2016 um 23:13 schrieb Marek Olšák:
>>>> On Mon, Aug 22, 2016 at 10:18 PM, Dave Airlie <airlied at gmail.com> wrote:
>>>>> On 23 August 2016 at 06:14, Marek Olšák <maraeo at gmail.com> wrote:
>>>>>> On Mon, Aug 22, 2016 at 7:05 PM, Brian Paul <brianp at vmware.com> wrote:
>>>>>>> On 08/22/2016 08:38 AM, Marek Olšák wrote:
>>>>>>>>
>>>>>>>> From: Marek Olšák <marek.olsak at amd.com>
>>>>>>>>
>>>>>>>> Sampler view declarations have return types, but that doesn't work with
>>>>>>>> variable indexing (e.g. SAMP[-1+i]).
>>>>>>>>
>>>>>>>> Adding the return type to the instruction is simpler.
>>>>>>>>
>>>>>>>> All sampler view declaration flags might have to be removed since variable
>>>>>>>> indexing makes them inaccessible.
>>>>>>>
>>>>>>>
>>>>>>> Do you want to get rid of sampler view declarations entirely?
>>>>>>
>>>>>> No, they have their place and I think the sampler view declarations
>>>>>> should stay, but the flags that are attached to them are basically
>>>>>> inaccessible with variable indexing. Since I have no reason to add
>>>>>> array support for sampler view declarations (unlike IN,OUT,TEMP, where
>>>>>> we needed array support due to other reasons), I prefer moving the
>>>>>> flags to instructions.
>>>>>
>>>>> It should be illegal in all APIs I thought to do mixed arrays.
>>>>>
>>>>> So if you have 1+x, then the bits on 1 should be the same as the
>>>>> bits on all the other sampler views in the array (even though there is
>>>>> no array).
>>>>>
>>>>> Is there a real world problem being solved?
>>>>
>>>> No, it's just for TGSI robustness (not to be confused with GL robustness).
>>>>
>>>
>>> I guess I replied to the wrong thread...
>>>
>>> In any case, I'd much prefer array support for sampler view dcls
>>> instead. Mixed arrays are illegal everywhere, and it's nice to see that
>>> in the translated shaders. And, even if you might not care on your hw,
>>> someone might benefit from separate arrays (I'm near certain a proper
>>> llvmpipe implementation of variable indexing would).
>>
>> Array support is a lot more work than this. I already did that for IN
>> and OUTs. I'm really not into it. I'm also not really into
>> DX10-anything as that's a deprecated API in the industry at this point
>> (if I ignore it's not even in Mesa).
>>
>
> I't nost so much about dx10 really. There's a reason noone allows mixed
> arrays. Using multiple arrays is a much more direct translation of glsl too.
> I'm sorry if properly fixing it is more work than a hack, but from my
> point of view interface cleanlyness wins by a long shot, so I'd still
> say NAK.

OK. No problem (really). I'll just do virgl does and rely on
glsl_to_tgsi behavior (which Dave wants to preserve anyway).

Marek