<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 14, 2020 at 5:15 PM Thomas Guillem <<a href="mailto:thomas@gllm.fr">thomas@gllm.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On Tue, Apr 14, 2020, at 16:57, Alexandre Janniaux wrote:<br>
> Hi,<br>
> <br>
> On Tue, Apr 14, 2020 at 05:45:18PM +0300, Rémi Denis-Courmont wrote:<br>
> > Le tiistaina 14. huhtikuuta 2020, 17.35.42 EEST Alexandre Janniaux a écrit :<br>
> > > Hi,<br>
> > ><br>
> > > Isn't vlc_CPU checked only in initialization steps to choose<br>
> > > the correct variant?<br>
> ><br>
> > No.<br></blockquote><div><br></div><div>Yes, mostly, only a few things stilll check at each call. (3 files IIRC, video_filter/sepia.c video_chroma/copy.c audio_filter/channel_mixer/simple_neon.c)</div><div>Otherwise it's only done in init.</div><div>(consider the other patches in the patchset which already change that for packetizer_startcode and deinterlacing filters)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Can't we just remove the few case where it's not calling it<br>
> during initialization? At the same time, it would remove<br>
> uneeded atomic operation on hot paths.<br>
<br>
Indeed, we could fix the few case where vlc_CPU is checked often.<br>
<br>
In that case, I'm OK with this patch, that is simplifying it a lot.<br></blockquote><div><br></div><div>Yeah so I started to do that on the parts I worked on (packetizer_startcode and deinterlace), a few things remain, but not much.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> It's mainly done your way in copy.c.<br>
> <br>
> ><br>
> > > What is the performance hit?<br></blockquote><div><br></div><div>Almost none anyway, it's just a test + conditional jmp / call, mostly, I don't know what "crap" the compiler puts around that.</div><div>But that's definitely not something you would be able to notice, in any case.</div><div>It's more of a good engineering thingy, don't call things over and over that will always return the same result, cache it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> ><br>
> > If you had read the patch, it would be obvious.<br></blockquote><div><br></div><div>If you had read the patchset, it would be obvious.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> I find this aggressive and irrelevant.<br></blockquote><div><br></div><div>Indeed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Regards,<br>
> --<br>
> Alexandre Janniaux<br>
> Videolabs<br>
> _______________________________________________<br>
> vlc-devel mailing list<br>
> To unsubscribe or modify your subscription options:<br>
> <a href="https://mailman.videolan.org/listinfo/vlc-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/vlc-devel</a><br>
_______________________________________________<br>
vlc-devel mailing list<br>
To unsubscribe or modify your subscription options:<br>
<a href="https://mailman.videolan.org/listinfo/vlc-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/vlc-devel</a></blockquote></div></div>