On Thu, Mar 15, 2018 at 1:12 AM, Alejandro Piñeiro <apinhe...@igalia.com> wrote:
> Hi, > On 14/03/18 21:32, Jason Ekstrand 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. > > > As part of the ongoing work for ARB_gl_spirv support we cover NIR, SPIR-V > (specially spirv-to-nir) from that list. Unfourtunately, I don't think that > it would be possible to land it before Monday, and we would need to deal > with the rebase problems. > > In hindsight, I think that we approached slightly wrong how we were > sending to review the sub-patches of the development series (btw, right > now, without cleaning it is ~100 patches). Our plan was sending patchsets > somewhat auto-contained. So a general spirv/nir change would be justified > for something we need for the ARB_gl_spirv nir-based linker we are writing > on the same patchset. That would mean more meaningful patchsets, but also > that somewhat mixed patchsets, and that one patchset is somewhat blocking > the following one. Taking into account how long the first patchset is > taking (something I assume that was caused by the GL 4.6 and anv 1.1 CTS > effort), that means that several spirv/nir patches were not sent to review. > Probably we should have send beforehand, even if out of context, some > "pure" spirv, spirv/nir patchsets, to at least checking if they were going > in the good direction. > I'm hoping that this change will not conflict as badly as I made it sound. If you're doing stuff that's actively touching derefs, then there may be a problem. If not, then there's a decent chance it won't conflict or if it does that it won't be bad. > In any case, as Im saying, this is all in hindsight reflection. > > Thanks for the warning, we will aware that next week (and likely following > ones) it would be complicated, and we would try several rebases during the > week, instead of the usual per-week rebase we are doing right now. > > 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 > listmesa-dev@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev > > >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
