[FFmpeg-devel] [PATCH] x86: kill fpel_mmx.c

[Michael Niedermayer]

On Mon, May 19, 2014 at 09:03:02PM +0200, Christophe Gisquet wrote:
> Hi,
> 
> tested by:
> - running configure with or without --disable-yasm
> - compiling
> - running: make fate-vc1 fate-cavs fate-h264 fate-dirac CPUFLAGS=mmx+mmxext
[...]
> diff --git a/libavcodec/x86/cavsdsp.c b/libavcodec/x86/cavsdsp.c
> index b45126c..a87cafd 100644
> --- a/libavcodec/x86/cavsdsp.c
> +++ b/libavcodec/x86/cavsdsp.c
> @@ -461,7 +461,7 @@ static void OPNAME ## cavs_qpel ## SIZE ## _mc03_ ## MMX(uint8_t *dst, uint8_t *
>  
>  #endif /* (HAVE_MMXEXT_INLINE || HAVE_AMD3DNOW_INLINE) */
>  
> -#if HAVE_MMX_INLINE
> +#if HAVE_YASM

why not HAVE_MMX_EXTERNAL ?


[...]

>  static void hpeldsp_init_mmxext(HpelDSPContext *c, int flags, int cpu_flags)
>  {
> +#if HAVE_YASM
> +    c->avg_pixels_tab[0][0] = avg_pixels16_mmxext;
> +    c->avg_pixels_tab[1][0] = ff_avg_pixels8_mmxext;
> +#endif
>  #if HAVE_MMXEXT_EXTERNAL
>      c->put_pixels_tab[0][1] = ff_put_pixels16_x2_mmxext;
>      c->put_pixels_tab[0][2] = put_pixels16_y2_mmxext;
>  
> -    c->avg_pixels_tab[0][0] = avg_pixels16_mmxext;
>      c->avg_pixels_tab[0][1] = avg_pixels16_x2_mmxext;
>      c->avg_pixels_tab[0][2] = avg_pixels16_y2_mmxext;
>  
>      c->put_pixels_tab[1][1] = ff_put_pixels8_x2_mmxext;
>      c->put_pixels_tab[1][2] = ff_put_pixels8_y2_mmxext;
>  
> -    c->avg_pixels_tab[1][0] = ff_avg_pixels8_mmxext;
>      c->avg_pixels_tab[1][1] = ff_avg_pixels8_x2_mmxext;
>      c->avg_pixels_tab[1][2] = ff_avg_pixels8_y2_mmxext;

why this change ?

also did you benchmark the change this patch makes ?
the original code was quite finetuned IIRC someone back then
tested all kinds of instruction orders and complex addressing vs
increasing the pointers, and what we had was the best found i that
testing ...
that was of course with the cpus of that time, but still a mmx only
or mmx2 only box for which some of this gets used could be similar

So we should make sure we dont worsen this ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140520/afbf19ad/attachment.asc>