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 <vivekvpan...@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@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
