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

Tue Aug 5 14:25:03 PDT 2014

>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.
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
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.
If you have multi-dimensional variables, you can index into the 2nd
dimension as well (I think only valid for constbuffers).

So I believe something like this should probably work in the end:
TEX TEMP[TEMP[0].x], SAMP[TEMP[1].x], TEMP[TEMP[2].x], etc

But for the sample opcodes I don't think indexing into the sampler would
be valid - the online docs say you can only declare single samplers, but
you can declare resource ranges (which we translate to individual
sampler view dcls, you could already declare ranges with d3d10 but since
you could not index into them dynamically until d3d11 ranges were not
required).

Roland

Am 05.08.2014 22:27, schrieb Marek Olšák:
> Using TEMPs instead of address registers seems to be the best choice
> here. It will need a CAP though, because some drivers will never
> support it. It might be quite a lot of work though.
> 
> Marek
> 
> On Tue, Aug 5, 2014 at 10:10 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> *needed*? No, I can't. However without changing a bunch of stuff
>> around, doing something like
>>
>> TEX TEMP[ADDR[0].x], SAMP[reladdr], coord, etc
>>
>> Is going to be tricky. It'd be a little dangerous to use ADDR[1] there
>> since it's meant to be the dimension, and you could easily have, with
>> tessellation,
>>
>> TEX OUT[ADDR[1].x][ADDR[0].x], SAMP[reladdr], ...
>>
>> Now I could obviously rewrite that as
>>
>> TEX TEMP[foo], SAMP[ADDR[0].x], ...
>> UARL ADDR[0]
>> UARL ADDR[1]
>> MOV OUT[ADDR[1].x][ADDR[0].x], TEMP[foo]
>>
>> But then I'd have to somehow communicate the emit() that it needs to
>> arrange for this. Not impossible, but tricky.
>>
>>   -ilia
>>
>> On Tue, Aug 5, 2014 at 4:04 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>> Could you please show us an example in TGSI where a 3rd address
>>> register is needed?
>>>
>>> Thanks,
>>>
>>> Marek
>>>
>>> On Tue, Aug 5, 2014 at 6:54 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> 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.)
>>>>
>>>> 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
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=7eULiloHHk8GglFEPUcMWPH5H4fe7WI4fWnVx0o0eHY%3D%0A&s=d74b9b91fb62ea04dfdfebe5048768ddf4020b8efc22513a3179076697f0d8d9
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=7eULiloHHk8GglFEPUcMWPH5H4fe7WI4fWnVx0o0eHY%3D%0A&s=d74b9b91fb62ea04dfdfebe5048768ddf4020b8efc22513a3179076697f0d8d9
> 