[FFmpeg-devel] [PATCH] avcodec/cfhd: add x86 SIMD

[Paul B Mahol]

On 8/15/20, Alexander Strasser <eclipse7 at gmx.net> wrote:
> Hi Derek,
> hi all!
>
> On 2020-08-14 20:22 +0100, Derek Buitenhuis wrote:
>> On 14/08/2020 20:13, Paul B Mahol wrote:
>> >> Resending because I accidentally replied to James instead of the list.
>> >> Woops.
>> >>
>> >> I guess it was not clear to me this is not the initial thread, since it
>> >> is
>> >> not
>> >> a v2 patch, and no other thread is titled this, or seems to include
>> >> SIMD?
>> >> Perhaps
>> >> I missed it.
>> >>
>> >> I still cannot actually locate any benchmarks in the various CFHD
>> >> threads.
>> >> If any were
>> >> done, as would be needed, to, like... test ones own SIMD code, they
>> >> should
>> >> be included
>> >> in the commit messages.
>> > Results differs between various CPUs and environments and also depends
>> > on
>> > encoded file resolution and quality.
>>
>> Well, yes. That never stopped anyone from providing information.
>>
>> > With my local patch I get overall several percent speed increase with
>> > only horiz_filter SSE2 applied.
>> > I also work on vert_filter SSE2 code, which currently give big speedup
>> > with lowest quality encodings and higher resolutions.
>> >
>> > For example:
>> >
>> > best quality 1080 60fps progressive yuv422p10 with additonal WIP
>> > vertical filter:
>> > cpuflags 0 speed : 0x243x realtime
>> > cpuflags sse2 speed: 0x353x realtime
>> >
>> > worst quality 1080 60fps progressive yuv422p10 with additional WIP
>> > vertical filter:
>> > cpuflags 0 speed: 0x348x realtime
>> > cpuflags sse2 speed: 0x811x realtime
>>
>> Thanks for finally providing some numbers. They should be in the commit
>> messgae.
>>
>> > Also I want reviews to be technical as possible, i have not sent this
>> > patch
>> > to listen to bad remarks but to get more improvements in assembly code
>> > if possible.
>>
>> Reviews of commit messages and methodolody or lack there of are valid
>> reviews.
>>
>> > If you are not assembly developer and are not willing to test patches
>> > better to
>> > stay away from this thread.
>>
>> See below
>>
>>
>> >
>> >> (Nice that we still silently ignore various insults from Paul thrown
>> >> around
>> >> by the way.)
>> > What specific insults in this thread?
>>
>> You wrote one just in this email, calling an ask for a better commit
>> message and
>> actual benchmarks "bad remarks", and previous wrote "You are not being
>> helpful at all.".
>>
>> See also above: "If you are not assembly developer and are not willing to
>> test patches better to
>> stay away from this thread."
>>
>> Frankly, it's disgusting that this community prefers to silently ignore
>> your (and others,
>> but lately, mostly your) abusive and unfriendly conduct.
>
> I have just read this thread.
>
> Derek's initial comment was clearly valid I would say:
>
>     I would expect any SIMD patch to include benchmarks showing it
>     is actually faster.

I "insulted" Derek only after he called me troll.

>
> IMHO what followed was way too much back and forth and not really
> nice at all. IMHO this kind of conversations are not for the good
> of the community and probably neither for the individuals having
> the conversation.
>
> So a better reply to Derek's concern would have been:
>
>     Here are my (preliminary) benchmarks on my not so
>     representative CPU.
>
> or
>
>     I will add benchmarks later and publish them before pushing.
>
>
> Not really related to this in general is the reproducibility of
> the benchmarks. That could be improved I think, but having some
> benchmarks included is rather a must have and better than having
> none.
>
>
> [...]
>
> Best regards,
>   Alexander
> _______________________________________________
> 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".