[Mesa-dev] [RFC] nir: compiler options for addressing modes

Connor Abbott cwabbott0 at gmail.com
Tue Apr 14 15:24:51 PDT 2015


On Tue, Apr 14, 2015 at 5:16 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Tue, Apr 14, 2015 at 4:59 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>>>>>> +   /**
>>>>>>> +    * Addressing mode for corresponding _indirect intrinsics:
>>>>>>> +    */
>>>>>>> +   nir_addressing_mode var_addressing_mode;
>>>>>>> +   nir_addressing_mode input_addressing_mode;
>>>>>>> +   nir_addressing_mode output_addressing_mode;
>>>>>>> +   nir_addressing_mode uniform_addressing_mode;
>>>>>>> +   nir_addressing_mode ubo_addressing_mode;
>>
>> What is var_addressing_mode?  Sorry for not bringing that up before.
>
>
> well, originally in my thinking it was for load_var/store_var..  but
> perhaps that doesn't make sense (given lower_io).  Maybe it makes more
> sense to define is as applying to var_local/var_global (where the
> others apply to shader_in/shader_out/uniform and their equivalent
> intrinsic forms)?
>
> Maybe it's a bit weird since I don't lower vars to regs before feeding
> to my ir3 frontend, but the whole load_var/store_var for array access,
> and ssa for everything else form works kind of nicely for me.
>
> BR,
> -R

I don't think we should be letting the driver define the stride of
variable array accesses. Variables are supposed to be structured,
backend-independent things that core NIR can manipulate and optimize
as it pleases; it shouldn't need to know anything about how the driver
will index the data. For doing the kinds of optimizations you're
talking about, you have registers that are backend-dependent, and core
NIR (other than the lower_locals_to_regs) doesn't need to know what
the indices mean. What you're doing right now is a hack, and if you
want to get the benefits of optimizing the index expression in core
NIR you should be using lower_locals_to_regs(). Having scalars be SSA
values and arrays be registers can't be that much more complicated
than having arrays be variables, and that's how it was set up to work
from the beginning.

Connor


More information about the mesa-dev mailing list