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

[timur.kristof at gmail.com]

Hi,

I'd like to complement Jason's excellent answer with some code
examples.

ac_nir_to_llvm is used by two drivers, RADV and RadeonSI.

Each of them have a driver-specific implementation of the shader ABI.
For RADV's implementation, take a look at llvm_compile_shader in
radv_nir_to_llvm.c and to see which NIR passes are used, take a look at
radv_shader_compile_to_nir in radv_shader.c

Hope this helps,
Timur

On Sun, 2020-10-11 at 10:08 -0500, Jason Ekstrand 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