Hi, On Sat, Jan 26, 2013 at 10:01 AM, Daniel Kang <[email protected]> wrote: > On Sat, Jan 26, 2013 at 3:23 AM, Diego Biurrun <[email protected]> wrote: >> On Sat, Jan 26, 2013 at 12:32:16AM -0500, Daniel Kang wrote: >>> --- a/libavcodec/x86/dsputil.asm >>> +++ b/libavcodec/x86/dsputil.asm >>> @@ -879,3 +884,984 @@ cglobal avg_pixels16, 4,5,4 >>> + >>> +; HPEL mmxext >>> +%macro PAVGB_OP 2 >>> +%if cpuflag(3dnow) >>> + pavgusb %1, %2 >>> +%else >>> + pavgb %1, %2 >>> +%endif >>> +%endmacro >> >> We have a macro for this in x86util.asm and it works the other way around. >> I'm very suspicious of this doing the right thing on CPUs with mmxext and >> 3dnow ... > > You're probably right. Fixed. > >>> +; mpeg4 qpel >>> + >>> +%macro MPEG4_QPEL16_H_LOWPASS 1 >>> +cglobal %1_mpeg4_qpel16_h_lowpass, 5, 5, 0, 8 >> >> So it seems like dsputil.asm is becoming the new dumping ground for >> functions of all kind. It doubles in size after your patch and at >> around 2k lines it starts to work against our current efforts of >> splitting dsputil into sensibly-sized pieces. If you continue your >> porting efforts, it will probably end up around 5k lines or so. >> >> Whenever there is an opportunity to make dsputil less monolithic comes >> up, we should exploit it. That seems to be the case here. > > I was trying to avoid drama and bikeshedding re: file names and save > that for another patch. I guess I could split it in this patch if you > want.
While at it, please split hpel functions to a new file called hpeldsp.asm. This will make my life slightly easier later on. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
