FWIW, the way I imagined doing this was something like: 1. Add nir_deref_instr and nir_deref_type_pointer. At this point, just make everything assert if the base deref isn't a nir_deref_var. This will be a bit of a flag-day, but also very mechanical. It'll also help us catch cases where we don't handle new-style derefs later. 2. Add a pass to flatten nir_deref_type_pointer into nir_deref_type_var if possible (i.e. if there's a clear chain up to the base variable without any phi nodes or whatever). This should always be possible for GLSL, as well as SPIR-V unless KHR_variable_pointers is enabled. We'll use this to avoid too much churn in drivers, passes that haven't been updated, etc. We might also want a pass to do the opposite, for converting passes where we don't want to have codepaths for both forms at once. 3. Modify nir_lower_io to handle new-style derefs, especially for shared variables (i.e. KHR_variable_pointers for anv). We might have to modify a few other passes, too. 4. Add the required deref lowering passes to all drivers. 5. Rewrite glsl_to_nir and spirv_to_nir to emit the new-style derefs. At the very least, we should be using this to implement the shared variable bits of KHR_variable_pointers. If we add stride/offset annotations to nir_deref_instr for UBO's and SSBO's, then we might also be able to get rid of the vtn_deref stuff entirely (although I'm not sure if that should be a goal right now).
At this point, we can fix things up and move everything else over to new-style derefs at our leisure. Also, it should now be pretty straightforward to add support for shared variable pointers to radv without lowering everything to offsets up-front, which is nice. Connor On Wed, Mar 14, 2018 at 2:32 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > All, > > Connor and I along with several others have been discussing for a while > changing the way NIR dereferences work. In particular, adding a new > nir_deref_instr type where the first one in the chain takes a variable and > is followed by a series of instructions which take another deref instruction > and do an array or structure dereference on it. > > Much of the motivation for this is some of the upcoming SPIR-V stuff where > we have more real pointers and deref chains don't really work anymore. It > will also allow for things such as CSE of common derefs which could make > analysis easier. This is similar to what LLVM does and it's working very > well for them. > > The reason for this e-mail is that this is going to be a flag-day change. > We've been talking about it for a while but this is going to be a major and > fairly painful change in the short term so no one has actually done it. > It's time we finally just suck it up and make it happen. While we will try > to make the change as incrementally and reviewably as possible but there is > a real limit as to what is possible here. My plan is to start cracking away > at this on Monday and hopefully have something working for i965/anv by the > end of the week or maybe some time the week after. If anyone has something > to say in opposition, please speak up now and not after I've spent a week > straight frantically hacking on NIR. > > I would like everyone to be respectful of the fact that this will be a major > change and very painful to rebase. If you've got outstanding NIR, GLSL, or > SPIR-V work that is likely to conflict with this, please try to land it > before Monday so that we can avoid rebase conflicts. If you have interest > in reviewing this, please try to be responsive so that we can get it > reviewed and landed before it becomes too painful. I'll try to send out > some preview patches as I go so that the data structures themselves can get > some review before the rest of the changes have been made. > > I'm also asking for help from Rob, Bas, and Eric if there are changes needed > in any of their drivers. I suspect the impact on back-end drivers will be > low because most of them don't use derefs directly, but it would be good of > people were on hand to help catch bugs if nothing else. > > Thanks, > > --Jason Ekstrand > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
