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

Marek Olšák maraeo at gmail.com
Wed Aug 24 09:26:59 UTC 2016


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

Marek


More information about the mesa-dev mailing list