<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 9, 2018 at 6:20 PM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Apr 9, 2018 at 4:58 PM, Caio Marcelo de Oliveira Filho <span dir="ltr"><<a href="mailto:caio.oliveira@intel.com" target="_blank">caio.oliveira@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Given the fixes you already made based on my comments. Patches 1-20,<br>
22-27, 29-43, and 61 (multiview!) are<br>
<br>
Reviewed-by: Caio Marcelo de Oliveira Filho <<a href="mailto:caio.oliveira@intel.com" target="_blank">caio.oliveira@intel.com</a>><br>
<br>
Patches 46-47 and 49 seem to be valid regardless the rest of the code,<br>
so I'd consider getting them in independently. They are also R-b'ed.<br></blockquote></span></div></div></div></blockquote><div><br></div><div>Good call.  I'll go ahead and land those once my Jenkins run completes.<br><br></div><div>--Jason<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></span><div>Thanks!<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've skipped 21 and 28 because I wanted to give a deeper look at the<br>
originals.<br>
<br>
>From the perspective of someone that is living with deref_vars for<br>
just a short time, I like the idea of removing one special<br>
construction (derefs) and rely on instructions instead.<br>
<br>
Which made me wonder: was there a special factor that led NIR to start<br>
with the "old-school derefs" in the first place? Other day Curro asked<br>
about one of the "selling points" of NIR being it did not have all<br>
those nodes representing dereferences. I digged up an old comment to<br>
what I think he was referring to<br>
<br>
    <a href="https://lists.freedesktop.org/archives/mesa-dev/2014-February/053477.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>archives/mesa-dev/2014-Februar<wbr>y/053477.html</a><br>
<br>
    - All the ir_dereference chains blow up the memory usage, and the<br>
    constant pointer chasing in the recursive algorithms needed to handle<br>
    them is not just cache-unfriendly but "cache-mean."<br>
<br>
How does deref_instructions avoid being "cache-mean" as their<br>
"predecessors"? Was the blow up more a result of how the instructions<br>
were structured than the fact it had those dereferences nodes?<br>
</blockquote></span></div><br></div><div class="gmail_extra">The blow up was mostly due to the fact that GLSL IR uses dereferences for *everything*.  NIR, in contrast, uses SSA defs for 95% of all temporary values so there simply aren't as many deref chains in play.<br></div></div>
</blockquote></div><br></div></div>