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

[Brian Paul]

On 03/11/2013 06:44 AM, 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.
>
> The solutions proposed or implemented so far all more or less incomplete, so
> this approach was designed in mind with both completeness and compatibility
> with existing code.
>
> Over all it's just an implementation of what Tom Stellard named solution #4 in
> this eMail thread: http://lists.freedesktop.org/archives/mesa-dev/2013-January/033264.html
>
> Please review and as usual comments are welcome,

I still don't quite get what's going on here.

In Christoph's reply, it seems he tested your patch and got TGSI code 
that looks like this:

DCL IN[0]
DCL IN[1]
DCL IN[2]
DCL OUT[0], POSITION
DCL OUT[1], GENERIC[12]
DCL OUT[2], GENERIC[13]
DCL OUT[3], GENERIC[14]
DCL OUT[4], GENERIC[15]
DCL CONST[0..1]
DCL TEMP[0..3], LOCAL
DCL TEMP[4], LOCAL
DCL ADDR[0]
IMM[0] FLT32 {    0.0000,     0.0000,     0.0000,     0.0000}
   0: UARL ADDR[0].x, CONST[1].xxxx
   1: MOV TEMP[4], IN[ADDR[0].x] <<< (not the bug) but this is invalid as
there is no IN array, just single ones
   2: MOV TEMP[0], IN[0]
   3: MOV TEMP[1], IN[1]
   4: MOV TEMP[2], IMM[0].xxxx
   5: MOV TEMP[3], IMM[0].xxxx
   6: UARL ADDR[0].x, CONST[0].xxxx
   7: MOV TEMP[1][ADDR[0].x], IN[2]

What exactly does "LOCAL" mean on the temp declarations?

But in Jose's example, he wrote:

   DCL TEMP[1][0..70]
   DCL TEMP[2][0..7]
   MOV OUT[1], TEMP[1][ADDR[0].x]

In this code, each chunk of temporaries has an explicit name as Marek 
suggested in his comments to the "#4" proposal.

What exactly is your proposal doing?

Can you please provide some more sample TGSI code to illustrate what 
you're doing?  And, how it would be extended for inputs/outputs?

Thanks.

-Brian