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

[Roland Scheidegger]

Am 30.01.2015 um 00:06 schrieb 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.

I think ideally this would be something the driver (or some util code)
should do. Some hardware has restrictions like "can't read 3 consts in a
MAD" which is similar from a theoretical standpoint but this is not
really something the glsl-to-tgsi code cares about or would really
matter at the tgsi level. I consider that shader obfuscation :-).


> 
> 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.

It actually sounds like there's a surprising number of hardware which
really still has address registers, even d3d10 capable one, and direct
support for manipulating them with things like ARL, so it seems it
wouldn't be easy to even get rid of that (it might be difficult for them
even when we would allow ARL to be used with temp regs as they'd still
needed to recognize it's used for indirect addressing). Hmm...

Roland