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

[Ilia Mirkin]

On Tue, Aug 5, 2014 at 10:28 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 05.08.2014 06:54, schrieb Ilia Mirkin:
>> Hello,
>>
>> I'm in the process of working out the details of adding dynamic
>> sampler support to mesa/st as part of ARB_gpu_shader5. Unfortunately
>> I've run into a bit of a roadblock.
>>
>> One approach I've tried is to load the indirect sampler index into an
>> address register and then use that as the offset. However in order to
>> realistically support that I need a 3rd address register, while right
>> now tgsi_ureg limits it to 2 address registers. Would it be OK to
>> relax the restriction to 3? (The reason I need a third is that if e.g.
>> the dst has a reladdr, I'd have to change a bunch of stuff to make
>> that function properly without a 3rd addr reg, since I can't just MOV
>> the sampler to a temp like it does for all the other src's.)
> I don't think using address regs is the right idea. This is essentially
> just for old ARB_vp address reg, they aren't really needed otherwise.
>
>>
>> Another apporach I've tried is to just use a TEMP register as the
>> indirect offset here. Unfortunately this gets destroyed by
>> st_glsl_to_tgsi's various optimizations which assume that temp
>> registers can't be reladdr's and so messes up the values. I started
>> adding support for that, but then quickly realized that was probably
>> not the right thing to do.
>>
>> So... should I increase the number of address registers to 1? Or is
>> there some other simple approach that I'm missing?
>>
>> Thanks,
>>
>>   -ilia
>
> As far as I understand, if you want to index samplers like that, you
> have to declare the samplers as an array, then just index into it like
> you'd do with other array types. So, my guess is that is what should be
> done, but maybe I don't understand the problem.

I'll double-check, but I thought that you indexed into array types
with address registers. It seems like any st_{src,dst}_reg.reladdr
value is always an address register (see translate_src -- it always
uses t->address[0/1]). However the ureg stuff will be more than happy
to take a temp register as the indirect, so perhaps what you're saying
is indeed reasonably supported.

TBH I haven't really internalized how/when array types are used in
TGSI. That may well be the simple solution I was looking for.
(Although it'd make for a lot more changes...)

  -ilia