[Mesa-dev] FLAG-DAY: NIR derefs

[Jason Ekstrand]

On Thu, Mar 15, 2018 at 1:12 AM, Alejandro Piñeiro <apinheiro at 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 at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180315/67b2f58b/attachment.html>