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

Rob Clark robdclark at gmail.com
Thu Jan 29 14:50:14 PST 2015


On Thu, Jan 29, 2015 at 5:31 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Thu, Jan 29, 2015 at 4:20 PM, Roland Scheidegger <sroland at 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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list