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

[Roland Scheidegger]

Am 06.08.2014 04:02, schrieb 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.
Yes that's right. I just thought that there's some code somewhere (for
instance ureg helpers and whatnot) possibly which would refuse this. And
_currently_ it's not really expected to work.

> 
>> 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.
I think ARL can easily be restricted to address reg (for compatibility
reasons probably easier to keep it).

> 
>> 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 this follows the pattern used elsewhere for temps, constants -
things you want to index into should be declared as an array (well it is
required by d3d10 at least, and I believe glsl as well). Ok I guess this
wasn't really required when using the address reg. This is easier for
verification, possibly useful for optimization (if you know which values
can't be indexed into) and just looks plain nicer in shader dumps :-).
Note that at least in some cases (can't remember off-hand if it affected
out-of-bound indices for indexing into such arrays) d3d10 has very
strict, crazy rules about out-of-bound values, and if you just flatten
everything you don't even know if it was out-of-bound. (GL also requires
some more strict behavior sometimes with newer versions, though I didn't
look this one up.)

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

Sounds like a sensible plan.

Roland