[Mesa-dev] RFC: mesa/st dynamic sampler support in tgsi

[Ilia Mirkin]

On Wed, Aug 6, 2014 at 10:52 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 06.08.2014 13:00, schrieb Marek Olšák:
>> On Wed, Aug 6, 2014 at 4:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> On Tue, Aug 5, 2014 at 5:25 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>>>> From a gallium perspective, indirect temp regs are already working - so
>>>> something like
>>>> MOV TEMP[0], TEMP[TEMP[1].x] should work.
>>>> Indirect registers are supported for inputs, outputs, temps, constants,
>>>> and immediates even, but the indirect reg itself must come from a temp
>>>> or address reg (I am not 100% certain where that restriction comes
>>>> from). I have no idea which drivers support it, all I can tell is that
>>>> it works with llvmpipe.
>>>> I sort of doubt it is supported for samplers right now in gallium though
>>>> technically it might be possible to express this already.
>>>
>>> Well, with my limited patch + ChrisF's small patches to mesa core, the
>>> dynamic sampler stuff works for nvc0, except for the issues I
>>> outlined. Not sure what you mean by "supported in gallium". Perhaps I
>>> have an incorrect view of things, but I see gallium as an amorphous
>>> thing that we can change to our heart's content.
>>>
>>>> A cap bit for the ability to support dynamic indexing of shaders (plus
>>>> whatever is needed for making it work like declaration of sampler
>>>> arrays) would certainly be needed in any case. For drivers supporting
>>>
>>> Right... so it's not like shaders will start magically containing
>>> these things, it'll only happen if ARB_gs5 is enabled (probably via
>>> PIPE_CAP_GLSL >= 400). Which presumably means that the backend
>>> supports whatever we're throwing at it.
>>>
>>>> this I would certainly expect them to allow temp regs as the indirect
>>>> reg. I guess it would be nice if we'd just use temp regs instead of
>>>> address reg in glsl to tgsi conversion if a driver supports it. I think
>>>> for modern drivers this makes a lot more sense than trying to shove
>>>> everything into address regs.
>>>
>>> Agreed. With the exception that I guess we also need to support
>>> indexing with float values? (i.e. ARL) This would have to be treated
>>> with some care. Not sure when that comes up though... perhaps only if
>>> !native_integers, which won't be an issue with any of the hw that
>>> we're talking about.
>>
>> If you really want to lower ARL into a temp, I recommend using F2I,
>> which is equivalent in behavior. For UARL, MOV will do.
>>
>> Also, I don't think GLSL sampler arrays have to be declared as arrays
>> in TGSI. Array declarations are really only needed for TEMPs, because
>> they allow better register allocation. Every other shader resource has
>> a fixed location and would not benefit from it.
> I think not requiring them to be declared as an array is a bad idea. It
> may well be true that hw drivers can't really benefit from it but in any
> case it would be trivial to handle in the drivers. It gives you the
> ability to easily see what values are legal in the end as a sampler
> index, might help with debugging at some day. Besides, it's just bad

You would see that based on the declarations anyways, no?

> style imho to index into things which aren't arrays, that is applicable
> to all languages, so I can't see why it should be different for tgsi.
> But I guess it's not all _that_ important.

Well, it might be important to put this in some context -- sampler
arrays are perfectly legal in GLSL today. What's not legal in pre-gs5
glsl (although based on some commends glsl 110 might have allowed it)
are the dynamic indices.

  -ilia