[Mesa-dev] [PATCH] mesa/st: add support for dynamic sampler offsets

[Roland Scheidegger]

Am 09.08.2014 17:25, schrieb Ilia Mirkin:
> On Sat, Aug 9, 2014 at 11:12 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 09.08.2014 16:33, schrieb Ilia Mirkin:
>>> On Sat, Aug 9, 2014 at 10:14 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>>>> On closer look, it looks to me like it wouldn't be all that difficult to
>>>> make proper sampler array dcls (as you apparently get them quite easily
>>>
>>> If you can briefly outline how you think that should be done, I'd be
>>> happy to try to do it. Right now the samplers are declared in
>>> st_translate_program, which only has the program->samplers_used
>>> bitfield (where program is glsl_to_tgsi_visitor).
>>>
>>> One quick thing that occurs to me is to keep track of samplers in a
>>> map of index -> array size (0 if it's not accessed indirectly or not
>>> an array), and then using the map to create the declarations. Does
>>> that seem reasonable?
>>>
>> Well I didn't think about it that much but nothing is stopping you from
>> putting whatever you need into the glsl_to_tgsi_visitor to keep that
>> array information instead of just filling out samplers_used.
>>
>>> Either way, this seems like a nice-to-have rather than required, so
>>> I'm going to push this patch even if the other one isn't ready.
>> Agreed. The address thingy is also something which should go away as
>> discussed but really separate issue too.
>> btw you get the actual sampler type from the constant in the sampler reg
>> right? So if you have
>> 4: TEX TEMP[1], TEMP[1], SAMP[ADDR[2].x+1], 2D
>> that +1 in there says the 2nd declared sampler determines what kind of
>> sampler this is (2d, 3d, shadow...).
> 
> From what I can tell, samplers (in TGSI) have no attached semantics...
Yeah you're right. All comes from textures (though it is sort of the same).

> they're just an index into an array that you're promised was set up
> correctly beforehand. For emitting the instructions, we look at the 2D
> from the tex instruction.
> 
> BTW, I have a follow-up patch that I'll send shortly which generates
> 
> FRAG
> PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
> DCL IN[0], GENERIC[0], PERSPECTIVE
> DCL OUT[0], COLOR
> DCL SAMP[0]
> DCL SAMP[1..3]
> DCL CONST[4]
> DCL TEMP[0..1], LOCAL
> DCL ADDR[0..2]
> IMM[0] FLT32 {    0.0000,     0.0000,     0.0000,     0.0000}
>   0: MOV TEMP[0].xy, IN[0].xyyy
>   1: TEX TEMP[0], TEMP[0], SAMP[0], 2D
>   2: MOV TEMP[1].xy, IN[0].xyyy
>   3: UARL ADDR[2].x, CONST[4].xxxx
>   4: TEX TEMP[1], TEMP[1], SAMP[ADDR[2].x+1], 2D
>   5: MAD TEMP[0], TEMP[0], IMM[0].xxxx, TEMP[1]
>   6: MOV OUT[0], TEMP[0]
>   7: END
> 
> Is that what you had in mind?
> 
That looks good to me. Would something like SAMP[ADDR[2].x+2] be illegal
with the above sampler declaration?

Roland