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

[Ilia Mirkin]

On Wed, Aug 6, 2014 at 11:15 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 06.08.2014 17:03, schrieb 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?
> How so? If you've got 15 samplers declared it is still not legal to
> index into the 15th one if your sampler array is starting at 0 with 5
> entries (or maybe it is legal but results undefined). That is at least
> my understanding of the spec. (Of course if I'm wrong here then indeed
> sampler arrays are worthless.)

That is indeed not legal. So right -- you wouldn't see where the
arrays are. But is that really worth worrying about at the TGSI level?
Anyways, I'll send my patch once perl gets unbroken on my system, and
you can rip it apart then :) Doing the array thing would be a giant
complication for what I perceive to be fairly little gain. The thing
is that the information of what's an array where is long lost by the
time the declarations are created -- there's just a bitmask of used
samplers.

>
>>
>>> 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.
> Yes, but without dynamically indexing into it the sampler array can
> easily be flattened since you always got the corresponding immediate
> "index". That is, it was never addressed as an array in tgsi.
> FWIW this is the same story with d3d10 - resource dcls could be arrays
> but the index had to be an immediate.
>
> Roland
>
>