On Mon, Aug 4, 2025 at 10:04 PM Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Mon, Aug 4, 2025 at 7:19 PM Jacob Lifshay <programmerj...@gmail.com> > wrote: > > > > > > > > On August 4, 2025 6:49:20 AM PDT, Alan Kelly via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > > > The gather is unmasked but the instruction does a merge into ymm4, > which > > > depends on the value of ymm4 from the previous loop iteration. The > > > out-of-order scheduler does not know statically that the instruction is > > > fully unmasked, preventing parallel out-of-order execution of the > > > gathers. > > > --- > > > libswscale/x86/scale_avx2.asm | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/libswscale/x86/scale_avx2.asm > b/libswscale/x86/scale_avx2.asm > > > index b4b852d60b..90ee8b0a0e 100644 > > > --- a/libswscale/x86/scale_avx2.asm > > > +++ b/libswscale/x86/scale_avx2.asm > > > @@ -68,8 +68,10 @@ cglobal hscale8to15_%1, 7, 9, 16, pos0, dst, w, > srcmem, filter, fltpos, fltsize, > > > .innerloop: > > > %endif > > > vpcmpeqd m13, m13 > > > + pxor m3, m3 ; break loop-carried dependency > > > > this is in AVX2 code, so you should use vpxor since pxor will just clear > the lower 128 bits and leave the upper 128 bits unmodified. actually, on > some older intel cpus it will cause a huge stall due to not being > v-prefixed: > > > https://stackoverflow.com/questions/41303780/why-is-this-sse-code-6-times-slower-without-vzeroupper-on-skylake/41349852#41349852 > > > > The v is actually automatically added by the pre-processor through > x86inc.asm if the function is marked as avx - its a bit confusing > because all other instructions are explicitly using it however, so it > might still be a good idea to be explicit about it. > > As for the patch itself, any numbers? > > - Hendrik > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > Thanks for the quick review and sorry for the slow response. I got dragged down a benchmarking rabbit hole. I was unable to reproduce the benchmarks I did when I originally ported hscale to avx2 on Skylake and Cascade Lake. I could only reproduce the speed-up on Broadwell and Sapphire Rapids. I found an Intel security vulnerability called Gather Data Sampling https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html which when mitigated, has a large impact on the performance of gather instructions. The machines I tested on had the mitigation applied, causing a huge performance loss for avx2 hscale. Broadwell: hscale_8_to_15__fs_4_dstW_512_c: 3379.5 ( 1.00x) hscale_8_to_15__fs_4_dstW_512_sse2: 615.7 ( 5.49x) hscale_8_to_15__fs_4_dstW_512_ssse3: 613.4 ( 5.51x) hscale_8_to_15__fs_4_dstW_512_avx2: 495.7 ( 6.82x) Skylake: hscale_8_to_15__fs_4_dstW_512_c: 3411.4 ( 1.00x) hscale_8_to_15__fs_4_dstW_512_sse2: 591.0 ( 5.77x) hscale_8_to_15__fs_4_dstW_512_ssse3: 591.5 ( 5.77x) hscale_8_to_15__fs_4_dstW_512_avx2: 1386.2 ( 2.46x) Cascade Lake: hscale_8_to_15__fs_4_dstW_512_c: 3231.3 ( 1.00x) hscale_8_to_15__fs_4_dstW_512_sse2: 517.9 ( 6.24x) hscale_8_to_15__fs_4_dstW_512_ssse3: 521.6 ( 6.19x) hscale_8_to_15__fs_4_dstW_512_avx2: 1775.0 ( 1.82x) Sapphire Rapids: hscale_8_to_15__fs_4_dstW_512_c: 1840.0 ( 1.00x) hscale_8_to_15__fs_4_dstW_512_sse2: 287.9 ( 6.39x) hscale_8_to_15__fs_4_dstW_512_ssse3: 293.8 ( 6.26x) hscale_8_to_15__fs_4_dstW_512_avx2: 219.2 ( 8.40x) This patch increases performance by about 3%. But I think the real question is what should be done about avx2 hscale? Most machines probably have this patch applied, should I send a patch removing avx2 hscale or disable it on Skylake, Ice Lake, Cascade Lake and possibly other machines? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
