[FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

Michael Niedermayer michael at niedermayer.cc
Sun Jul 10 20:25:50 EEST 2016


On Sun, Jul 10, 2016 at 01:39:01PM -0300, James Almer wrote:
> On 7/10/2016 8:36 AM, Michael Niedermayer wrote:
> > On Sun, Jul 10, 2016 at 07:08:19AM -0400, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Thu, Jul 7, 2016 at 8:51 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> On Thu, Jul 7, 2016 at 7:38 AM, Michael Niedermayer <
> >>> michael at niedermayer.cc> wrote:
> >>>
> >>>> On Thu, Jul 07, 2016 at 07:14:43AM -0400, Ronald S. Bultje wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On Thu, Jul 7, 2016 at 7:07 AM, Michael Niedermayer
> >>>> <michael at niedermayer.cc>
> >>>>> wrote:
> >>>>>
> >>>>>> On Wed, Jul 06, 2016 at 07:28:27AM -0500, Dan Parrot wrote:
> >>>>>>> On Wed, 2016-07-06 at 09:07 +0200, Hendrik Leppkes wrote:
> >>>>>> [...]
> >>>>>>
> >>>>>>>
> >>>>>>> One other thing: why didn't this come up when the earlier patch was
> >>>>>>> submitted and applied?
> >>>>>>
> >>>>>> community patch review is not a reproduceable process, depending on
> >>>>>> who has time and does the review, different things can be found and
> >>>>>> pointed out, and people have also different oppinions.
> >>>>>> Real consistency can possibly only be achived by having an active
> >>>>>> maintainer that does all review ...
> >>>>>>
> >>>>>> To be more precisse the other patch was applied due to this comment
> >>>>>> IIRC:
> >>>>>>  "If this patch works (FATE passes on ppc64) and is faster than
> >>>>>>   the plain c functions then it can be committed as is"
> >>>>>
> >>>>>
> >>>>> How much faster was it?
> >>>>
> >>>> There where several benchmarks posted, one is here:
> >>>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-June/196022.html
> >>>> it also contains some arguments why the speedup is less than on x86
> >>>
> >>>
> >>> I don't think these numbers are very convincing...
> >>>
> >>> The arguments, on the other hand, are not facts, they are hunches, so they
> >>> are essentially meaningless.
> >>>
> >>> I would suggest to revert the patch
> >>>
> >> [..]
> >>
> >> So, this hasn't been reverted yet, is there any particular reason why it
> >> hasn't?
> >>
> >> Again, the speedup is practically meaningless, the code unreviewed, and it
> >> will have to be rewritten by whoever finishes #5570. Can we please agree
> >> reverting is the best option - and then revert?
> > 
> > i think if you want to "mentor" this you should just do what you need
> > to do to mentor this ...
> 
> Ronald is asking for people's opinion, since reverting it without
> consulting others first (especially the committer) is not nice.

as iam the commiter, if it wasnt clear already, i really have no
oppinion, at least not in the form of taking any offense from any
action. If anything then complete non-action in leaving this unresolved
would feel offending.

The part where i do have an oppinon, is incremental development, i do
like incremental development, optimizing code in steps or implementing
codecs stepwise in the main repository with feedback from users and
collaboration of other developers. Thats how a lot of code in FFmpeg
was developed. And I tend to enjoy it more to work
on something in smaller steps than to sit on a growing patchset which
noone really uses=tests.
But thats not what we have here. The code here seems to be abadoned
and there remain unawnsered questions ...

It could be reverted, it could be left for the next developer to use
as starting point, i have no oppinion on this.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160710/ecc3c74d/attachment.sig>


More information about the ffmpeg-devel mailing list