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 <imir...@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 <mar...@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 <imir...@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@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@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev