[Mesa-dev] killing off the address reg in tgsi

[Brian Paul]

On 01/29/2015 02:20 PM, Roland Scheidegger wrote:
> Hi,
>
> the address reg in tgsi is quite a nuisance. glsl-to-tgsi code assumes
> that indirections can only be done through the address reg and has quite
> some extra code to deal with this. Even though hardware and apis which
> worked like that are definitely old by now.
> Thus, I'm proposing the address reg be nuked. I am however not quite
> sure what the implications for drivers are, other than I'm certain
> llvmpipe can handle that already.
> For that reason, I suspect at least initially a new cap bit would be
> required so glsl-to-tgsi would skip the extra code. I tend to think
> longer term it would be great if it could be nuked completely, I am
> however not sure if that is easily done with drivers for old hw (such as
> r300) - I guess if necessary we could keep operations such as ARL (or
> even ARR though clearly not UARL!) and just define them to be usable
> with temp regs.
>
> Opinions?

Sounds good, but as you know, the vmware/svga driver uses the address 
register.

Currently, there's some handy code in st_glsl_to_tgsi.cpp which looks 
for instructions where more than one operand uses indirect addressing 
and reduces it down to one indirection per instruction.

For example, if we had something like this:

uniform vec4 a[10], b[10], c[10];
x = a[i] * b[j] + c[k];

We get TGSI code something like this:

ARL ADDR.x, i;
MOV TEMP[0], CONST[ADDR.x];
ARL ADDR.x, j;
MOV TEMP[1], CONST[ADDR.x];
ARL ADDR.x, k;
MAD TEMP[2], TEMP[0], TEMP[1], CONST[ADDR.x];

(and yes, I can see the desire to get rid of that entirely and emit 
something like:
MAD TEMP[2], CONST[TEMP_i], CONST[TEMP_j], CONST[TEMP_k];
)


If we added a new cap along the lines of 
"PIPE_CAP_MAX_INDIRECTIONS_PER_INSTRUCTION" we could keep that logic in 
the state tracker.  This would make life easier in the driver(s).

Otherwise, if we discard ADDR, ARL and don't have the new cap, the 
driver(s) will have to count the indirections in each instruction and 
load some of those operands into temp registers.

It's do-able, but more work.  It would take me a while to implement that 
in our driver.  Of course, some of it could go into a TGSI lowering utility.

In any case, the driver would still have to detect patterns like this:

OPCODE DST, SRC[TEMP], ...

and convert it to

ARL ADDR.x, TEMP;
OPCODE DST, SRC[ADDR.x], ...

But that's not too hard.

-Brian