Re: [Mesa-dev] Rust drivers in Mesa
On Fri, 2020-10-02 at 12:53 -0500, Jason Ekstrand wrote: > On Fri, Oct 2, 2020 at 11:34 AM Eric Anholt wrote: > > On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig > > wrote: > > > Hi all, > > > > > > Recently I've been thinking about the potential for the Rust > > > programming > > > language in Mesa. Rust bills itself a safe system programming > > > language > > > with comparable performance to C [0], which is a naturally fit > > > for > > > graphics driver development. > > > > > [...] > > That said, I really do like Rust as a language. I'm not sure I'd go > quite as far as Anholt but I feel like it has everything I like about > C++ without most of what I dislike. I'm not sure how we would do > things like ANV's GenXML multi-compile magic but I'm sure we could > figure out a way. I'd love to see someone build something in Rust > and > figure out some best practices. > > --Jason The good thing about C++ is that you can pick a subset of features that you like, and stick to them. Then you'll never have to deal with other the stuff if you don't want to. There exists a subset of the language which helps get rid of most memory management issues. I would also argue that there exist a bunch of tools that can help make C/C++ code stay safe, for example our collegaue Tony has recently addressed some findings by an undefined behaviour sanitizer. There are also free and open source static analyzers. I like the idea of Rust, especially their intention to focus on safety, but honestly, I don't like how they realized it. The Rust syntax is slightly annoying. They departed from C/C++ enough to make Rust look different, but then they got lazy and for some reason they chose to keep the most annoying parts from C/C++ like curly braces and semicolons, so even if we switch to Rust we can still enjoy debating important topics like where to put curly braces, how many spaces or tabs are best, and so on. My main concern is that memory is just one of many resources that we need to use safely, but it's the only one that Rust concerns itself with. Memory safety can give you a false sense of security. It's possible to write insecure apps that are perfectly memory safe. That said, I think it's perfectly okay to give it a try, write a backend compiler in Rust and see what happens. However, I don't think it is feasible or desireable to rewrite complicated parts from C/C++ to Rust. I think Daniel Steinberg's thoughts apply: https://daniel.haxx.se/blog/2017/03/27/curl-is-c/ Best regards, Tim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rust drivers in Mesa
On Fri, 2020-10-02 at 18:21 -0500, Jason Ekstrand wrote: > > The good thing about C++ is that you can pick a subset of features > > that > > you like, and stick to them. Then you'll never have to deal with > > other > > the stuff if you don't want to. There exists a subset of the > > language > > which helps get rid of most memory management issues. > > The difficulty in Mesa has always been deciding what that subset is. > This thread is proof of that. So far we've had people extole > everything from basic type safety and memory management to template > meta-programming. Features which one developer enjoys another > loathes. This is why we tend to stick to C for the core: It's > limited > but those limitations we can sort-of all agree on it. Yes, the bad thing about C++ is that it has a lot of baggage. Sometimes I find myself enjoying writing C more, because then I get to spend more time on the actual problems I'm solving. In C++ there are a lot of ways to do everything so I have to think more about which fits the task at hand best. My only problem with C is that it lacks something like the STL which means that every project has to reinvent the wheel to some degree; and that it lacks things like generics, so there isn't a good way to avoid repetitive code. > IMO: Like many modern languages, Rust has a defined default coding > style and It's pretty reasonable. We should just go with it. Fair point. > > That said, I think it's perfectly okay to give it a try, write a > > backend compiler in Rust and see what happens. However, I don't > > think > > it is feasible or desireable to rewrite complicated parts from > > C/C++ to > > Rust. I think Daniel Steinberg's thoughts apply: > > https://daniel.haxx.se/blog/2017/03/27/curl-is-c/ > > Same. Different developers/teams make different choices in their > drivers and back-ends all the time. Some use C++ while others stickk > to C. They all have different coding styles and choose different C++ > feature sets (when they use C++). IMO, the choice to use a language > like Rust is no different. As long as it doesn't cause a giant > project-wide problem, I'm fine with it. Yeah, nothing wrong with that. I'll be curious to see how it turns out. - Tim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var
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 > 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
