<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 15, 2018 at 1:12 AM, Alejandro Piñeiro <span dir="ltr"><<a href="mailto:apinheiro@igalia.com" target="_blank">apinheiro@igalia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Hi,<br>
</p><span class="">
<div class="m_-4940576761448368096moz-cite-prefix">On 14/03/18 21:32, Jason Ekstrand
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>All,<br>
<br>
</div>
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.<br>
<br>
</div>
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.<br>
<br>
</div>
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.<br>
<br>
</div>
<div>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. <br>
</div>
</div>
</blockquote>
<br></span>
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.<br>
<br>
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.<br></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
In any case, as Im saying, this is all in hindsight reflection.<br>
<br>
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.<br>
<br>
<blockquote type="cite"><span class="">
<div dir="ltr">
<div> 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.<br>
</div>
<div><br>
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.<br>
<br>
</div>
<div>Thanks,<br>
<br>
</div>
<div>--Jason Ekstrand<br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="m_-4940576761448368096mimeAttachmentHeader"></fieldset>
<br>
</span><pre>______________________________<wbr>_________________
mesa-dev mailing list
<a class="m_-4940576761448368096moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a>
<a class="m_-4940576761448368096moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div><br></div></div>