On Wed, Mar 5, 2014 at 6:11 PM, Anton Khirnov <[email protected]> wrote:
>
> On Wed, 05 Mar 2014 10:59:20 -0500, Justin Ruggles <[email protected]> 
> wrote:
>> On 03/05/2014 09:25 AM, Anton Khirnov wrote:
>> > On Wed, 05 Mar 2014 08:56:52 -0500, Justin Ruggles 
>> > <[email protected]> wrote:
>> >> On 03/05/2014 04:43 AM, Luca Barbato wrote:
>> >>> diff --git a/libavfilter/af_volume.c b/libavfilter/af_volume.c
>> >>> index 12d496e..2cdfe23 100644
>> >>> --- a/libavfilter/af_volume.c
>> >>> +++ b/libavfilter/af_volume.c
>> >>> @@ -262,6 +262,7 @@ static int filter_frame(AVFilterLink *inlink, 
>> >>> AVFrame *buf)
>> >>>                   vol->scale_samples(out_buf->extended_data[p],
>> >>>                                      buf->extended_data[p], 
>> >>> plane_samples,
>> >>>                                      vol->volume_i);
>> >>> +                emms_c();
>> >>>               }
>> >>>           } else if (av_get_packed_sample_fmt(vol->sample_fmt) == 
>> >>> AV_SAMPLE_FMT_FLT) {
>> >>>               for (p = 0; p < vol->planes; p++) {
>> >> Neither of the dsp functions used in af_volume utilize MMX registers.
>> >> Adding emms_c() is completely pointless.
>> >>
>> > That requires the caller to know this.
>> >
>> > And we might add such functions in the future (unlikely, but still 
>> > possible)
>> >
>>
>> What caller are you referring to, and why would they have to know
>> anything? Littering the code with unnecessary emms seems pretty silly to
>> me. If someone happens to add more MMX/3DNow functions (they better have
>> a very good reason...) it's up to them to add the required emms either
>> in their function or in the appropriate places where that function is used.
>>
>
> I mean the caller of float_dsp does not know what kind of functions are used 
> in
> it. Or we should document it that functions requiring emms are not used and
> ban them forever.
>

Is it very likely to get MMX code written these days, and not at least SSE/SSE2?
Maybe put a notice in float_dsp to warn people. :p

- Hendrik
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to