[FFmpeg-devel] [PATCH] swscale: Break loop-carried dependency enabling parallel out of order execution of the gathers.

[Alan Kelly]

On Mon, Aug 4, 2025 at 10:04 PM Hendrik Leppkes <h.leppkes at gmail.com> wrote:

> On Mon, Aug 4, 2025 at 7:19 PM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> >
> >
> > On August 4, 2025 6:49:20 AM PDT, Alan Kelly via ffmpeg-devel <
> ffmpeg-devel at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at 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?