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

[Roland Scheidegger]

Am 06.08.2014 17:20, schrieb 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.
Oh I wasn't aware of that I thought you got that information pretty easily.
Yeah in that case I guess it's not worth bothering. In any case we could
tighten that up later if necessary.

Roland


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