<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 9, 2018 at 4:41 PM, Bas Nieuwenhuizen <span dir="ltr"><<a href="mailto:bas@basnieuwenhuizen.nl" target="_blank">bas@basnieuwenhuizen.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Apr 10, 2018 at 12:37 AM, Rob Clark <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote:<br>
> On Mon, Apr 9, 2018 at 1:35 AM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
>> Rather lively discussion we've got going here...<br>
>><br>
>> On Sun, Apr 8, 2018 at 3:23 PM, Rob Clark <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote:<br>
>>><br>
>>> On Sun, Apr 8, 2018 at 5:54 PM, Bas Nieuwenhuizen<br>
>>> <<a href="mailto:bas@basnieuwenhuizen.nl">bas@basnieuwenhuizen.nl</a>> wrote:<br>
>>> > On Sun, Apr 8, 2018 at 11:40 PM, Rob Clark <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote:<br>
>>> >> On Sun, Apr 8, 2018 at 5:20 PM, Bas Nieuwenhuizen<br>
>>> >> <<a href="mailto:bas@basnieuwenhuizen.nl">bas@basnieuwenhuizen.nl</a>> wrote:<br>
>>> >>><br>
>>> >>> You mean insert it into the fatptr every time deref_cast is called?<br>
>>> >>><br>
>>> >>> Wouldn't that blow up the IR size significantly for very little<br>
>>> >>> benefit?<br>
>>> >><br>
>>> >> in an easy to clean up way, so meh?<br>
>>> ><br>
>>> > We can't clean it up if we want to keep the information. Also nir is<br>
>>> > pretty slow to compile already, so I'd like not to add a significant<br>
>>> > number of instruction for very little benefit.<br>
>><br>
>><br>
>> Really?  I mean, I can believe it, but do you have any actual numbers to<br>
>> back this up?  It's considerably faster than some other IRs we have in mesa<br>
>> though they are known to be pretty big pigs if we're honest.  I'm very open<br>
>> to any suggestions on how to improve compile times.  If NIR is fundamentally<br>
>> a pig, we should fix that.<br>
>><br>
><br>
> just a side-note, I guess mostly obvious but just pointing it out<br>
> because it has caught others by surprise.  Debug mesa builds by<br>
> default run nir_validate after every pass (unless you NIR_VALIDATE=0).<br>
> And this adds a *lot* of overhead (for a *lot* of debugging benefit)..<br>
><br>
> But if nir seems slow when running shader-db/etc, if you are using a<br>
> debug build at least make sure to NIR_VALIDATE=0 (or better yet use a<br>
> release build) when measuring performance<br>
<br>
</div></div>Yeah I was aware of that. Given this discussions I've actually run<br>
some numbers for radv with a cold shader cache:<br>
<br>
time total: 76.507337 sec<br>
spirv 1.625971 sec<br>
nir_to_llvm 10.146195 sec<br>
llvm 46.058714 sec<br></blockquote><div><br></div><div>Ok, that's more-or-less what I would have expected.  I'm a bit surprised that spirv_to_nir is so expensive but there's some crazy juggling we have to do in there.  We could probably improve it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
hence total - spirv - nir_to_llvm - llvm = ~18.7 sec which is mostly due to nir.<br>
</blockquote></div><br></div><div class="gmail_extra">Which is only 40% of the time you spend in LLVM. :-)  If you're letting NIR optimize, I expect it to take some real time but it doesn't look too bad.<br><br></div><div class="gmail_extra">I'm a bit surprised how long nir_to_llvm takes though...<br></div></div>