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

[Mike Blumenkrantz]

Possibly worth noting as another point for reference is that zink also uses
variables.

On Sun, Oct 11, 2020, 11:08 AM Jason Ekstrand <jason at jlekstrand.net> wrote:

> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20201011/9138d56a/attachment.htm>