On Fri, Nov 14, 2014 at 09:00:31PM -0700, Pavel Koshevoy wrote:
> On 11/14/14 07:34, Michael Niedermayer wrote:
> >On Fri, Nov 14, 2014 at 06:45:55AM -0700, Pavel Koshevoy wrote:
> >>On Nov 13, 2014 4:15 PM, "Michael Niedermayer" <michae...@gmx.at> wrote:
> >>>On Fri, Nov 07, 2014 at 03:12:19PM +0100, Michael Niedermayer wrote:
> >>>>This needs to be benchmarked, i do not have ppc hw
> >>>>This is on big endian more similar to how the code was before
> >>79e0255956bc8fcdb143f39b2e45db77144ac017
> >>>>Signed-off-by: Michael Niedermayer <michae...@gmx.at>
> >>>ping
> >>>
> >>>can someone with a altivec PPC please benchmark this
> >>>or do all the ppc people want code to be slow and unoptimized ?
> >>>iam also happy to benchmark it myself if someone provides a ppc or
> >>>account on a altivec ppc that is reasonable idle so benchmarking is
> >>>possible with some accuracy
> >>>
> >>I can do it over the weekend, I have a ppc G4 800MHz iMac. I'll need
> >>instructions on what to do for benchmarking.
> >patch that adds benchmarking is below
> >that and trying to decode some mpeg2 like with
> > -v 99 -i matrixbench_mpeg2.mpg -f null -
> >
> >should result in some timing values
> >i cant say for sure though, as this does not work under qemu
> >under qemu i just get 0
> >
> >
> >diff --git a/libavcodec/mpegvideo_motion.c b/libavcodec/mpegvideo_motion.c
> >index e7a585d..94b140d 100644
> >--- a/libavcodec/mpegvideo_motion.c
> >+++ b/libavcodec/mpegvideo_motion.c
> >@@ -976,6 +976,7 @@ void ff_mpv_motion(MpegEncContext *s,
> > op_pixels_func (*pix_op)[4],
> > qpel_mc_func (*qpix_op)[16])
> > {
> >+ START_TIMER
> > #if !CONFIG_SMALL
> > if (s->out_format == FMT_MPEG1)
> > mpv_motion_internal(s, dest_y, dest_cb, dest_cr, dir,
> >@@ -984,4 +985,5 @@ void ff_mpv_motion(MpegEncContext *s,
> > #endif
> > mpv_motion_internal(s, dest_y, dest_cb, dest_cr, dir,
> > ref_picture, pix_op, qpix_op, 0);
> >+ STOP_TIMER("MC")
> > }
> >
> >
>
> git am wouldn't apply the patches for me (I just saved the message
> from Thunderbird to .eml file and tried to feed that to git am). So,
> I had to trim them and use patch -p1 to apply manually. The patch
> for util_altivec.h wouldn't apply so I patched manually.
> > I ran both builds twice and captured the output from the second run > of each build, it's in the attachment. By the looks of it there is > no difference in performance. to compare START/STOP_TIMER data its generally best to run the test a few times (like 3) and compare the values from each that have some specific number or runs, like > 681 UNITS in MC, 4192359 runs, 1945 skips0:01:40.88 bitrate=N/A vs. > 668 UNITS in MC, 4192326 runs, 1978 skips0:01:40.16 bitrate=N/A but from these 2 tests it seems you are correct and theres no significant difference so theres probably not much point in doing further tests Thanks! PS: if the tests take too long, a shorter video can be used or the duration can be limited > > If you'd like me to try something else -- I can try again tomorrow. > > Pavel. > [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
