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