>-----Original Message----- >From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@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" <mich...@niedermayer.cc> >> > 发送时间: 2019-08-08 07:05:13 (星期四) >> > 收件人: "FFmpeg development discussions and patches" >> > <ffmpeg-devel@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
