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

[Roland Scheidegger]

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

Roland


> 
> If GLSL is strict about out-of-bounds access, I recommending always
> clamping the index in glsl_to_tgsi.
> 
> Marek
>