[Mesa-dev] FLAG-DAY: NIR derefs

Thu Mar 15 15:08:33 UTC 2018

On 15/03/18 15:39, Jason Ekstrand wrote:
> On Thu, Mar 15, 2018 at 1:12 AM, Alejandro Piñeiro
> <apinheiro at igalia.com <mailto: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.

Ah, good to know. Just skimming, we only have one patch using derefs, so
even if we need to update it, it shouldn't be a big deal.

Thanks for the update.

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