On Thu, Jan 29, 2015 at 5:31 PM, Rob Clark <robdcl...@gmail.com> wrote: > On Thu, Jan 29, 2015 at 4:20 PM, Roland Scheidegger <srol...@vmware.com> > 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? > > Not sure about other hw (although I would assume radeon is similar).. > but adreno has real actual address register, which need to be used for > relative addressing of the register (or const) file. Otherwise we'd > need to do something like arrays in memory and load/store > instructions. > > Possibly w/ more smarts in the compiler, we could infer address > register usage. It would require some smarts that we don't have yet > to eliminate redundant writes to the address register generated for > each instruction with indirect reference.
actually, I think I'm lying.. since it will end up SSA form (in either tgsi->ir3 or tgsi->nir->ir3), we should have a single address register value, so maybe it isn't such a big problem.. BR, -R > (Although eventually I'd like to use tgsi->nir.. and haven't yet > looked at how nir handles indirects so maybe eventually I need to > implement those smarts in my compiler anyway.) > > BR, > -R > > >> Roland >> _______________________________________________ >> 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
