For those interested in following along, I've pushed a bunch of stuff to a branch:
https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/nir-deref-instr I will continue force-pushing that branch as I go. My current approach to doing things incrementally is to try and do it by type of dereference initially. It'll be tricky when I start using deref instructions for local variables as that's where most of the passes want to use them. --Jason On Wed, Mar 14, 2018 at 1: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
