[Mesa-dev] FLAG-DAY: NIR derefs

[Alejandro Piñeiro]

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.

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 list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180315/d750afda/attachment-0001.html>