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

[Rob Clark]

On Thu, Jan 29, 2015 at 6:06 PM, Brian Paul <brianp at vmware.com> wrote:
> 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).
>

that would make it easier for me at least.. :-)

otherwise I end up lowering the second form back into the first

BR,
-R


> 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
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev