[Mesa-dev] [PATCH v3 000/104] nir: Move to using instructions for derefs

[Jason Ekstrand]

On Mon, Apr 9, 2018 at 6:20 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Mon, Apr 9, 2018 at 4:58 PM, Caio Marcelo de Oliveira Filho <
> caio.oliveira at intel.com> wrote:
>
>> Hi,
>>
>> Given the fixes you already made based on my comments. Patches 1-20,
>> 22-27, 29-43, and 61 (multiview!) are
>>
>> Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira at intel.com>
>>
>> Patches 46-47 and 49 seem to be valid regardless the rest of the code,
>> so I'd consider getting them in independently. They are also R-b'ed.
>>
>
Good call.  I'll go ahead and land those once my Jenkins run completes.

--Jason


> Thanks!
>
>
>> I've skipped 21 and 28 because I wanted to give a deeper look at the
>> originals.
>>
>> From the perspective of someone that is living with deref_vars for
>> just a short time, I like the idea of removing one special
>> construction (derefs) and rely on instructions instead.
>>
>> Which made me wonder: was there a special factor that led NIR to start
>> with the "old-school derefs" in the first place? Other day Curro asked
>> about one of the "selling points" of NIR being it did not have all
>> those nodes representing dereferences. I digged up an old comment to
>> what I think he was referring to
>>
>>     https://lists.freedesktop.org/archives/mesa-dev/2014-Februar
>> y/053477.html
>>
>>     - All the ir_dereference chains blow up the memory usage, and the
>>     constant pointer chasing in the recursive algorithms needed to handle
>>     them is not just cache-unfriendly but "cache-mean."
>>
>> How does deref_instructions avoid being "cache-mean" as their
>> "predecessors"? Was the blow up more a result of how the instructions
>> were structured than the fact it had those dereferences nodes?
>>
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180409/6d2bed93/attachment.html>