On Thu, Jan 29, 2015 at 6:06 PM, Brian Paul <bri...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
