[FFmpeg-devel] [PATCH v4] avutil/mips: refine msa macros CLIP_*.

[Shiyou Yin]

>-----Original Message-----
>From: ffmpeg-devel-bounces at ffmpeg.org [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of
>Michael Niedermayer
>Sent: Friday, August 9, 2019 12:07 AM
>To: FFmpeg development discussions and patches
>Subject: Re: [FFmpeg-devel] [PATCH v4] avutil/mips: refine msa macros CLIP_*.
>
>On Thu, Aug 08, 2019 at 09:49:35AM +0800, 顾希伟 wrote:
>> > 发件人: "Michael Niedermayer" <michael at niedermayer.cc>
>> > 发送时间: 2019-08-08 07:05:13 (星期四)
>> > 收件人: "FFmpeg development discussions and patches"
>> > <ffmpeg-devel at ffmpeg.org>
>> > 抄送:
>> > 主题: Re: [FFmpeg-devel] [PATCH v4] avutil/mips: refine msa macros CLIP_*.
>> >
>> > On Wed, Aug 07, 2019 at 05:52:00PM +0800, gxw wrote:
>> > > Changing details as following:
>> > > 1. Remove the local variable 'out_m' in 'CLIP_SH' and store the result in
>> > >    source vector.
>> > > 2. Refine the implementation of macro 'CLIP_SH_0_255' and 'CLIP_SW_0_255'.
>> > >    Performance of VP8 decoding has speed up about 1.1%(from 7.03x to 7.11x).
>> > >    Performance of H264 decoding has speed up about 0.5%(from 4.35x to 4.37x).
>> > >    Performance of Theora decoding has speed up about 0.7%(from 5.79x to 5.83x).
>> > > 3. Remove redundant macro 'CLIP_SH/Wn_0_255_MAX_SATU' and use 'CLIP_SH/Wn_0_255'
>> > >    instead, because there are no difference in the effect of this two macros.
>> >
>> > can these 3 things be split into 3 patches ?
>> > It would be clearer if each change would be in its own patch
>> >
>> > thanks
>> >
>> > [...]
>>
>> It can be split into 3 patches. But there some benefits as 1 patch, these macros belong to the same
>>class and are highly relevant. It is more intuitive to put them in a patch.
>
>hmm
>does anyone else has any oppinion about this ?
>
>if not ill apply it
>

In fact, change 2 and 3 is related closely. it's using a new macro to replace 'CLIP_SH/Wn_0_255' and
 'CLIP_SH/Wn_0_255_MAX_SATU'. So, It's better to put 2&3 in one patch. 
Change 1 belongs to the same macro type of change 2&3. Putting it together is mainly because of there are
too many macros are pending refactor, It's a balance between patch complexity and patch number.
So it's acceptable to me.