<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 3, 2013 at 10:19 AM, Derek Buitenhuis <span dir="ltr"><<a href="mailto:derek.buitenhuis@gmail.com" target="_blank">derek.buitenhuis@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10/1/2013 6:50 PM, Steve Borho wrote:<br>
> This is the effort to get rid of the GPL vector class headers   We're replacing primitives that use those classes with intrinsics because the GPL headers have to be gone by November and we prefer not crippling what performance we have today.<br>

><br>
> At our current pace of assembly development, it would take about two years to replace them all with assembly and we don't have that luxury.<br>
><br>
> Assembly development will continue in parallel with this effort; but there will be a lot of patches in the coming weeks that replace vector class based intrinsic primitives with pure-intrinsic primitives; or just deleting vector primitives that we don't care enough about to keep.<br>

<br>
</div>I'll translate:<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[14:37] < j-b> seriously, is that that hard to do .asm files instead of writing new intrinsincs?<br></blockquote><div><br></div><div>These aren't new intrinsics, they're replacing existing intrinsics.  And yes, anyone following the progress of the chroma 4-tap interpolation assembly can clearly see this assembly effort has been slow to get off the ground.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[15:47] < Daemon404> j-b, intrinsics are faster because they dont get reviewed.<br></blockquote><div><br></div><div>the first intrinsic patch was reviewed and rejected; though to be honest it was reviewed by one of our guys.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[15:47] < Daemon404> as opposed to Skyler_'s asm review<br>
[15:48] < Daemon404> i also love the arbitrary november date<br></blockquote><div><br></div><div>x265 will have a limited commercial deployment in November; commercial deployment means no non-dual-licensed code.  It is what is is; unless someone is going to volunteer an army of assembly coders this is what we have to do.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[15:49] < Daemon404> oh holy sad intrinsics spam...<br>
[15:50] < Daemon404> there's no way that isn't just copy/pasted bullshit.<br>
[16:08] < Daemon404> also<br>
[16:08] < Daemon404> arent these (copy/pasted?) intrinsics possibly going to be super crappy<br>
[16:08] < Daemon404> due to register allocation</blockquote></div><div><br></div><div>SAD routines are pretty boring, and there is some ugly hand-unrolling going on.. but our SAD intrinsics are in the neighborhood of x264 SAD assembly perf.</div>
<div><br></div><div>These new routines are generally twice as fast as the vector class based routines they're replacing.</div><div><br></div><div>The 4-tap chroma interpolation assembly function we've just finished is only a hair faster than the intrinsic-based primitive  (16x vs 15x faster than C).</div>
<div><br></div>-- <br>Steve Borho
</div></div>