[FFmpeg-devel] [PATCH 02/12] Add fill_float to dsputil

[Reimar Döffinger]

On Sun, Sep 27, 2009 at 11:49:18AM +0100, Mans Rullgard wrote:
> ---
>  libavcodec/dsputil.c |    7 +++++++
>  libavcodec/dsputil.h |    1 +
>  2 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/libavcodec/dsputil.c b/libavcodec/dsputil.c
> index 16f2d25..2ffb1ba 100644
> --- a/libavcodec/dsputil.c
> +++ b/libavcodec/dsputil.c
> @@ -4055,6 +4055,12 @@ WRAPPER8_16_SQ(quant_psnr8x8_c, quant_psnr16_c)
>  WRAPPER8_16_SQ(rd8x8_c, rd16_c)
>  WRAPPER8_16_SQ(bit8x8_c, bit16_c)
>  
> +static void fill_float_c(float *dst, float v, int n)
> +{
> +    while (n--)
> +        *dst++ = v;
> +}
> +
>  static void vector_fmul_c(float *dst, const float *src, int len){
>      int i;
>      for(i=0; i<len; i++)
> @@ -4794,6 +4800,7 @@ void dsputil_init(DSPContext* c, AVCodecContext *avctx)
>  #if CONFIG_FLAC_ENCODER
>      c->flac_compute_autocorr = ff_flac_compute_autocorr;
>  #endif
> +    c->fill_float = fill_float_c;
>      c->vector_fmul = vector_fmul_c;
>      c->vector_fmul_reverse = vector_fmul_reverse_c;
>      c->vector_fmul_add = vector_fmul_add_c;
> diff --git a/libavcodec/dsputil.h b/libavcodec/dsputil.h
> index 7d27d25..8af06ff 100644
> --- a/libavcodec/dsputil.h
> +++ b/libavcodec/dsputil.h
> @@ -385,6 +385,7 @@ typedef struct DSPContext {
>      void (*ac3_downmix)(float (*samples)[256], float (*matrix)[2], int out_ch, int in_ch, int len);
>      /* no alignment needed */
>      void (*flac_compute_autocorr)(const int32_t *data, int len, int lag, double *autoc);
> +    void (*fill_float)(float *dst, float v, int n);
>      /* assume len is a multiple of 8, and arrays are 16-byte aligned */
>      void (*vector_fmul)(float *dst, const float *src, int len);
>      void (*vector_fmul_reverse)(float *dst, const float *src0, const float *src1, int len);

I'm not sure if a fill_uint32 wouldn't be better, since it is more
versatile and maybe even faster/easier to SIMGify (I seem to remember
that I encountered a few other functions that implement their own 32 bit
fill, but maybe I imagine it).
Of course it would be a bit uglier to use...