[Mesa-dev] [RFC] Solving the TGSI indirect addressing optimization problem

[Christoph Bumiller]

On 11.03.2013 15:38, Christian König wrote:
> Am 11.03.2013 14:47, schrieb Christoph Bumiller:
>> On 11.03.2013 13:44, Christian König wrote:
>>> Hi everybody,
>>>
>>> this problem has been open for quite some time now, with a bunch of
>>> different
>>> opinions and sometimes even patches floating on the list.
>> Nice, finally someone implements a proper solution.
>> However, it seems like this isn't used for arrays in the IN and OUT
>> files (varyings). Would it be much more work to use it there, too ?
>
> Shouldn't be to much of a problem, but I just wanted to solve
> temporaries first and when that's working look at all the rest.
>
>> Fragment Shader inputs seem to be read with "if (index == 0) return
>> in[0] else if (index == 1) ..." sequences.
>
> Well as said before it only handles temp arrays for now. That looks
> like the code that's generated if the driver reports to not have
> indirect support, do you know off hand where exactly that's handled?
> The glsl_to_tgsi code is unfortunately hard to read at best.
>

Apologies, I didn't remember I that I didn't advertise indirect support
for fragment shaders, indirect inputs would be supported though.
The reason why I really want array support for inputs, too, is that
input space location depends on semantic, and thus doesn't necessarily
correspond to the TGSI order.

Treatment of arrays should be consistent in the end, right now it looks
like we're having, if you read this like C code:
float temp0[4];
temp0[i] = x;

but
float in0, in1, in2, in3;
x = in[i];

>> why is this TEMP[1][] ? The array seems to be the first declaration ...
>
> I numbered the declarations starting with 1 (and not 0), so I could
> use 0 as "the SPECIAL case" saying that we want to address the whole
> range of registers and not just one declaration. I did this just for
> compatibility reasons, so I could look at handling temps only, and
> doesn't bother to much with inputs/outputs.
>
> Well so far the patchset is just an RFC, and so I want to let the list
> see the patches before either implementing inputs/outputs as well or
> fully document such quirks/hacks.
>

Ah, good to know. This should be documented (maybe it is and I missed it
?). At least in the comment above struct tgsi_ind_register's definition,
which is what I'd look at first.

Thanks again for doing this.