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

[Roland Scheidegger]

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.

Roland