[FFmpeg-devel] [PATCH] ppc: replace vec_ld(0), vec_ld(1) by VEC_LD2() which has fewer loads

James Almer jamrial at gmail.com
Sun Nov 16 02:12:16 CET 2014


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" <michaelni at 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 <michaelni at 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


More information about the ffmpeg-devel mailing list