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

[Roland Scheidegger]

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).

Roland