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

[Ilia Mirkin]

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

Would there be any advantage to not just flattening the arrays? That's
easiest right now, I don't see what we gain by keeping them as arrays.
You need to store a base index either way.

I think I'm going to implement it with the extra address reg for now,
since that's what will work in st_glsl_to_tgsi the easiest. Once
Bryan's patch to rework all of that is in, we'll be able to add a cap
to just not deal with address registers at all, in which case we can
also decree that in order to support the relative sampler indexes, you
also need to support not using address registers and get rid of that
extra logic.

  -ilia