[Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var

[Jason Ekstrand]

First off, I should point out that the AMD NIR -> LLVM translator is,
as far as I know, the only NIR back-end that consumes variables at
all.  Most back-ends assume that all variable access is completely
lowered away before the back-end ever sees it.  How this is done
depends on the variable mode.

For nir_var_shader_temp, these are typically converted to
nir_var_function_temp by nir_lower_global_vars_to_local after function
inlining has completed.  For nir_var_function_temp, it's some
combination of nir_lower_vars_to_ssa, nir_lower_indirect_derefs, and
nir_lower_locals_to_regs.  If the back-end wants to be able to handle
indirect access (such as with a non-constant array index) directly, it
will typically use nir_lower_locals_to_regs.  If the back-end doesn't
want to handle indirects, it will use nir_lower_indirect_derefs to get
rid of any indirects at which point nir_lower_vars_to_ssa will get rid
of all access to nir_var_function_temp variables assuming complete
deref chains.  (Incomplete deref chains can happen with OpenCL kernel
so they require a different approach.)

Next, we have driver-internal I/O for things like vertex attributes,
varyings, and uniforms, i.e. nir_var_shader_in, nir_var_shader_out,
and nir_var_uniform.  This is typically handled by nir_lower_io.  This
call takes a type_size callback function which it ses to lay out the
I/O data in some sort of index space.  For nir_var_uniform, this is
often bytes (but doesn't have to be).  For nir_var_shader_in and
nir_var_shader_out, it's typically in units of vec4 locations.  The
result of this lowering is a bunch of load/store_input/output
intrinsics.  For FS inputs, nir_lower_io can optionally produce
interpolation intrinsics instead.

The final major category is external I/O.  For this, we use
nir_lower_explicit_io and friends.  One difference between
nir_lower_io and nir_lower_explicit_io is that nir_lower_explicit_io
expects types to have explicit layout information (which is always in
units of bytes) rather than taking it from a callback.  Another
difference is that nir_lower_explicit_io is capable of handling
incomplete deref chains where pointer casts, pointer arithmetic, and
other weirdness may exist while nir_lower_io assumes full deref chains
all the time.  For Vulkan, we need explicit type layout information
because that's what we get from SPIR-V and we need partial deref
chains because of extensions like VK_KHR_variable_pointers.  For
OpenGL, we have neither of those things but we use
nir_lower_explicit_io anyway because we want the consistency and
because the std140/430 layouts are a little too complex to describe
with the callback used by nir_lower_io.

Lastly, we have nir_var_system_value which is lowered by
nir_lower_system_values and nir_lower_cs_system_values.

I hope that helps.  I should really turn this into a blog post or,
better yet, real documentation....

--Jason

On Sun, Oct 11, 2020 at 6:27 AM vivek pandya <vivekvpandya at gmail.com> wrote:
>
> I see that
> visit_load_var() in ~/mesa/src/amd/llvm/ac_nir_to_llvm.c
>
> assumes that nir_variable used in this intrinsic can have few specific mods only.
>
> For example variable can not have nir_var_mem_shared , if such mod encountered it will execute unreachable() code.
>
> Is there any nir pass that needs to be run before nir_to_llvm translation?
>
> Sincerely,
> Vivek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev