[Mesa-dev] FLAG-DAY: NIR derefs

[Connor Abbott]

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 <jason at 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
>