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

[Ilia Mirkin]

On Mon, Aug 11, 2014 at 10:56 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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?

Didn't give it much thought... definitely couldn't actually happen
given the code that's there. However if the code were to be refer to
foo[n+1] and we had a constant folding + propagation pass in TGSI,
then I guess that could happen. In fact, SAMP[ADDR[2].x+10000] could
happen under those conditions as well. But we have no such passes at
the TGSI level, so it should be fine. And when we acquire such passes,
we can teach them not to futz with the constant in SAMP[] offsets,
while still allowing the downstream driver to do any optimization it
wishes.

  -ilia