Re: [FFmpeg-devel] [PATCH 04/15] avfilter/vf_bwdif: Add neon for filter_intra

["Martin Storsjö" <martin@martin.st>]

On Sun, 2 Jul 2023, John Cox wrote:

> On Sun, 2 Jul 2023 00:37:35 +0300 (EEST), you wrote:
>
>>> +
>>> +        uaddl           v20.8h,  v31.8b,  v30.8b
>>> +        uaddl2          v21.8h,  v31.16b, v30.16b
>>> +
>>> +        UMULL4K         v2, v3, v4, v5, v20, v21, v0.h[6]
>>> +
>>> +        uaddl           v20.8h,  v29.8b,  v28.8b
>>> +        uaddl2          v21.8h,  v29.16b, v28.16b
>>> +
>>> +        UMLSL4K         v2, v3, v4, v5, v20, v21, v0.h[7]
>>> +
>>> +//        dst[0] = av_clip(interpol, 0, clip_max);
>>> +        SQSHRUNN        v2, v2, v3, v4, v5, 13
>>> +        str             q2, [x0], #16
>>> +
>>> +//        dst++;
>>> +//        cur++;
>>> +//    }
>>> +
>>> +        subs            w2,  w2,  #16
>>> +        add             x1,  x1,  #16
>>
>> For in-order cores, it might be good to update these variables sometime
>> sooner, e.g. before the str instruction. But such scheduling breaks your
>> mapping between neat C code and assembly.
>
> I take your point but there is at least 1 instruction between set and
> use which is normally enough.

True, in most cases, it's enough, but sometimes you can save more if 
there's a stall bubble elsewhere too.

> I did my benching on a Pi4 and found, to my surprise, that in most cases
> reordering instructions to interleavse operations made life worse and
> seeing as Pi4 is my target platform I stopped trying to do that and
> stuck with code that was easier to read! (Also filter_intra seems to be
> much more memory b/w limited than code limited on a Pi4.)

A Raspberry Pi 4 is Cortex A72, and that one has got out of order 
execution, so you generally won't be able to notice most of the effects of 
instruction scheduling. On actual in-order cores, like Cortex A53 (found 
in e..g the Pi3 and lots of other places), scheduling can have a fairly 
dramatic effect though.

In any case, here it's not a big concern, and one instruction inbetween 
usually is good enough indeed.

// Martin

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".