On 15/11/14 1:50 AM, Michael Niedermayer wrote:
> 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
>
It might be a good idea to try -threads 1 for the input file as well
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
