Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Tue, Nov 3, 2015 at 1:20 PM, Ganesh Ajjanagadde wrote: > On Tue, Nov 3, 2015 at 12:54 PM, Muhammad Faiz wrote: >> On Tue, Nov 3, 2015 at 3:47 AM, Ganesh Ajjanagadde wrote: >>> On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz wrote: On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde wrote: > On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer > wrote: >> On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote: >>> On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer >>> wrote: >>> > From: Michael Niedermayer >>> > >>> > This should fix the build failure of avf_showcqt.c >>> > >>> > An alternative solution would be to add a check for fmin/fmax to >>> > fate-source and >>> > then to replace them by FFMIN/FFMAX, i can do that if preferred? >>> > >>> > Untested due to lack of a affected platform >>> >>> I recall some interest on my end to get fmin, fmax etc for different >>> reasons, and it was remarked that commit >>> 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary >>> seems to be that getting it to work on all platforms is not so simple. >> >> :/ >> ill replace the problematic ones by FFMIN/MAX for now so the build >> failure on the affected msvc platforms is fixed >> tieing a build fix to this complexity would be unwise >> >> >>> I am definitely interested in getting it to work in order to replace >>> FFMAX/FFMIN for floating point in especially libavfilter. This will >>> allow better nan signalling at a slight performance cost. >> >> would that performance cost affect all systems or just ones not >> having fmin/fmax ? >> i think affecting all systems would be bad > > A correct fmin and fmax will be slower than FFMIN/FFMAX, simply > because they do NaN handling. How much slower, I have not tested. Also > note that flags may be passed to the compiler to ignore NaN's, > something which can possibly be done locally if desired. However, I > view FFMAX/FFMIN as the cleaner solution if NaN signalling/propagation > is not an issue, so I may not pursue this. > Common problem with FFMIN/FFMAX (and other macros that evaluates arguments more than once): FFMAX(a, myfunc(b)) will call myfunc twice (OK compiler may optimize it and call myfunc once) and often people don't care about it. >>> >>> That goes without saying, but sometimes compiler can't optimize due to >>> sequence point stuff. This is why the macro should be used cautiously. >>> However, FFmpeg devs are generally cautious about these things so I no >>> longer press this that hard. The real technical benefit (if any) is >>> the different NaN handling as noted above. >> >> Here some examples: >> libavfilter/g729postfilter.c: 544 >> *voicing = FFMAX(*voicing, long_term_filter(adsp, pitch_delay_int, >> residual, >> residual_filt_buf + 10, >> subframe_size)); >> >> others that call sqrt, strlen, etc (altough possibly compiler can optimize >> it) >> >> commit 94494dab910133106e80ece0f79935d78138e415 >> +volume = FFABS(av_expr_eval(volume_expr, expr_vars_val, NULL)); >> I posted the patch, and I didn't noticed or warned that it is wrong. > > So on the note of FFABS - I think all floating point usages at least > have been converted to proper C functions. > > Yes, things like this can be missed, and I personally use the libc > variants unless there is no alternative. > However, it was quite some work for me to convince others to use them, > and I am trying to stay on the sidelines this time by not posting a > patch for it. > OK, it is just matter of programming style, whatever we choose, has advantages and deficiency. The most important thing is that it is work. Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Tue, Nov 3, 2015 at 12:54 PM, Muhammad Faiz wrote: > On Tue, Nov 3, 2015 at 3:47 AM, Ganesh Ajjanagadde wrote: >> On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz wrote: >>> On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde >>> wrote: On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer wrote: > On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote: >> On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer >> wrote: >> > From: Michael Niedermayer >> > >> > This should fix the build failure of avf_showcqt.c >> > >> > An alternative solution would be to add a check for fmin/fmax to >> > fate-source and >> > then to replace them by FFMIN/FFMAX, i can do that if preferred? >> > >> > Untested due to lack of a affected platform >> >> I recall some interest on my end to get fmin, fmax etc for different >> reasons, and it was remarked that commit >> 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary >> seems to be that getting it to work on all platforms is not so simple. > > :/ > ill replace the problematic ones by FFMIN/MAX for now so the build > failure on the affected msvc platforms is fixed > tieing a build fix to this complexity would be unwise > > >> I am definitely interested in getting it to work in order to replace >> FFMAX/FFMIN for floating point in especially libavfilter. This will >> allow better nan signalling at a slight performance cost. > > would that performance cost affect all systems or just ones not > having fmin/fmax ? > i think affecting all systems would be bad A correct fmin and fmax will be slower than FFMIN/FFMAX, simply because they do NaN handling. How much slower, I have not tested. Also note that flags may be passed to the compiler to ignore NaN's, something which can possibly be done locally if desired. However, I view FFMAX/FFMIN as the cleaner solution if NaN signalling/propagation is not an issue, so I may not pursue this. >>> >>> Common problem with FFMIN/FFMAX (and other macros that evaluates >>> arguments more than once): >>> FFMAX(a, myfunc(b)) >>> will call myfunc twice (OK compiler may optimize it and call myfunc once) >>> and often people don't care about it. >> >> That goes without saying, but sometimes compiler can't optimize due to >> sequence point stuff. This is why the macro should be used cautiously. >> However, FFmpeg devs are generally cautious about these things so I no >> longer press this that hard. The real technical benefit (if any) is >> the different NaN handling as noted above. > > Here some examples: > libavfilter/g729postfilter.c: 544 > *voicing = FFMAX(*voicing, long_term_filter(adsp, pitch_delay_int, > residual, > residual_filt_buf + 10, > subframe_size)); > > others that call sqrt, strlen, etc (altough possibly compiler can optimize it) > > commit 94494dab910133106e80ece0f79935d78138e415 > +volume = FFABS(av_expr_eval(volume_expr, expr_vars_val, NULL)); > I posted the patch, and I didn't noticed or warned that it is wrong. So on the note of FFABS - I think all floating point usages at least have been converted to proper C functions. Yes, things like this can be missed, and I personally use the libc variants unless there is no alternative. However, it was quite some work for me to convince others to use them, and I am trying to stay on the sidelines this time by not posting a patch for it. > > Thank's > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Tue, Nov 3, 2015 at 9:21 AM, Hendrik Leppkes wrote:
> On Tue, Nov 3, 2015 at 5:10 PM, Muhammad Faiz wrote:
>> On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote:
>>> On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote:
On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
> On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer
> wrote:
> > From: Michael Niedermayer
> >
> > This should fix the build failure of avf_showcqt.c
> >
> > An alternative solution would be to add a check for fmin/fmax to
> > fate-source and
> > then to replace them by FFMIN/FFMAX, i can do that if preferred?
> >
> > Untested due to lack of a affected platform
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > configure|8
> > libavutil/libm.h | 28
> > 2 files changed, 36 insertions(+)
> >
> > diff --git a/configure b/configure
> > index 95790f4..e6f5d2c 100755
> > --- a/configure
> > +++ b/configure
> > @@ -1770,6 +1770,10 @@ MATH_FUNCS="
> > exp2
> > exp2f
> > expf
> > +fmax
> > +fmaxf
> > +fmin
> > +fminf
> > isinf
> > isnan
> > ldexpf
> > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
> > disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h
> > DtsCrystalHDVersion -lcrystalhd || disable crystalhd
> >
> > atan2f_args=2
> > +fmax_args=2
> > +fmaxf_args=2
> > +fmin_args=2
> > +fminf_args=2
> > copysign_args=2
> > ldexpf_args=2
> > powf_args=2
> > diff --git a/libavutil/libm.h b/libavutil/libm.h
> > index 6c17b28..ba837a2 100644
> > --- a/libavutil/libm.h
> > +++ b/libavutil/libm.h
> > @@ -43,6 +43,34 @@
> > #define atan2f(y, x) ((float)atan2(y, x))
> > #endif
> >
> > +#if !HAVE_FMAX
> > +#undef fmax
> > +static av_always_inline double fmax(double x, double y)
> > +{
> > +if (x < y) return y;
> > +else return x;
> > +}
> > +#endif
> > +
> > +#if !HAVE_FMIN
> > +#undef fmin
> > +static av_always_inline double fmin(double x, double y)
> > +{
> > +if (x < y) return x;
> > +else return y;
> > +}
> > +#endif
>
> Wasn't there a concern that these emulations don't behave identical to
> the C library versions in regards to NaN handling?
> I faintly remember something in the previous discussion.
yes, i forgot about that :(
i replaced them by FFMIN / FFMAX
>>>
>>> Sorry to raise this again but i htink it must handle NaN, or we need to
>>> use a av_ prefix to define our own semantic.
>>>
>> It seems good to do both
>> use fmax*/fmin* to support NaN handling
>> and add av_* (probably av_max*/av_min*) to make it more consistent
>> with av_clip*/etc
>
> If a function with side-effects is used inside FFMIN/FFMAX, thats a
> simple bug and should be fixed.
> We don't need to introduce new functions for that. av_clip* exists
> because they are quite a bit more complex than min/max, and even have
> architecture specific optimized versions in some cases.
>
> - Hendrik
If a function without side-effect is used inside FFMIN/FFMAX, the code
is correct,
but the function may be called twice and it will degrade performance.
Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Tue, Nov 3, 2015 at 3:47 AM, Ganesh Ajjanagadde wrote: > On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz wrote: >> On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde >> wrote: >>> On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer >>> wrote: On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote: > On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer > wrote: > > From: Michael Niedermayer > > > > This should fix the build failure of avf_showcqt.c > > > > An alternative solution would be to add a check for fmin/fmax to > > fate-source and > > then to replace them by FFMIN/FFMAX, i can do that if preferred? > > > > Untested due to lack of a affected platform > > I recall some interest on my end to get fmin, fmax etc for different > reasons, and it was remarked that commit > 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary > seems to be that getting it to work on all platforms is not so simple. :/ ill replace the problematic ones by FFMIN/MAX for now so the build failure on the affected msvc platforms is fixed tieing a build fix to this complexity would be unwise > I am definitely interested in getting it to work in order to replace > FFMAX/FFMIN for floating point in especially libavfilter. This will > allow better nan signalling at a slight performance cost. would that performance cost affect all systems or just ones not having fmin/fmax ? i think affecting all systems would be bad >>> >>> A correct fmin and fmax will be slower than FFMIN/FFMAX, simply >>> because they do NaN handling. How much slower, I have not tested. Also >>> note that flags may be passed to the compiler to ignore NaN's, >>> something which can possibly be done locally if desired. However, I >>> view FFMAX/FFMIN as the cleaner solution if NaN signalling/propagation >>> is not an issue, so I may not pursue this. >>> >> >> Common problem with FFMIN/FFMAX (and other macros that evaluates >> arguments more than once): >> FFMAX(a, myfunc(b)) >> will call myfunc twice (OK compiler may optimize it and call myfunc once) >> and often people don't care about it. > > That goes without saying, but sometimes compiler can't optimize due to > sequence point stuff. This is why the macro should be used cautiously. > However, FFmpeg devs are generally cautious about these things so I no > longer press this that hard. The real technical benefit (if any) is > the different NaN handling as noted above. Here some examples: libavfilter/g729postfilter.c: 544 *voicing = FFMAX(*voicing, long_term_filter(adsp, pitch_delay_int, residual, residual_filt_buf + 10, subframe_size)); others that call sqrt, strlen, etc (altough possibly compiler can optimize it) commit 94494dab910133106e80ece0f79935d78138e415 +volume = FFABS(av_expr_eval(volume_expr, expr_vars_val, NULL)); I posted the patch, and I didn't noticed or warned that it is wrong. Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Tue, Nov 3, 2015 at 5:10 PM, Muhammad Faiz wrote:
> On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote:
>> On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote:
>>> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
>>> > On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer
>>> > wrote:
>>> > > From: Michael Niedermayer
>>> > >
>>> > > This should fix the build failure of avf_showcqt.c
>>> > >
>>> > > An alternative solution would be to add a check for fmin/fmax to
>>> > > fate-source and
>>> > > then to replace them by FFMIN/FFMAX, i can do that if preferred?
>>> > >
>>> > > Untested due to lack of a affected platform
>>> > >
>>> > > Signed-off-by: Michael Niedermayer
>>> > > ---
>>> > > configure|8
>>> > > libavutil/libm.h | 28
>>> > > 2 files changed, 36 insertions(+)
>>> > >
>>> > > diff --git a/configure b/configure
>>> > > index 95790f4..e6f5d2c 100755
>>> > > --- a/configure
>>> > > +++ b/configure
>>> > > @@ -1770,6 +1770,10 @@ MATH_FUNCS="
>>> > > exp2
>>> > > exp2f
>>> > > expf
>>> > > +fmax
>>> > > +fmaxf
>>> > > +fmin
>>> > > +fminf
>>> > > isinf
>>> > > isnan
>>> > > ldexpf
>>> > > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
>>> > > disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h
>>> > > DtsCrystalHDVersion -lcrystalhd || disable crystalhd
>>> > >
>>> > > atan2f_args=2
>>> > > +fmax_args=2
>>> > > +fmaxf_args=2
>>> > > +fmin_args=2
>>> > > +fminf_args=2
>>> > > copysign_args=2
>>> > > ldexpf_args=2
>>> > > powf_args=2
>>> > > diff --git a/libavutil/libm.h b/libavutil/libm.h
>>> > > index 6c17b28..ba837a2 100644
>>> > > --- a/libavutil/libm.h
>>> > > +++ b/libavutil/libm.h
>>> > > @@ -43,6 +43,34 @@
>>> > > #define atan2f(y, x) ((float)atan2(y, x))
>>> > > #endif
>>> > >
>>> > > +#if !HAVE_FMAX
>>> > > +#undef fmax
>>> > > +static av_always_inline double fmax(double x, double y)
>>> > > +{
>>> > > +if (x < y) return y;
>>> > > +else return x;
>>> > > +}
>>> > > +#endif
>>> > > +
>>> > > +#if !HAVE_FMIN
>>> > > +#undef fmin
>>> > > +static av_always_inline double fmin(double x, double y)
>>> > > +{
>>> > > +if (x < y) return x;
>>> > > +else return y;
>>> > > +}
>>> > > +#endif
>>> >
>>> > Wasn't there a concern that these emulations don't behave identical to
>>> > the C library versions in regards to NaN handling?
>>> > I faintly remember something in the previous discussion.
>>>
>>> yes, i forgot about that :(
>>> i replaced them by FFMIN / FFMAX
>>>
>>
>> Sorry to raise this again but i htink it must handle NaN, or we need to
>> use a av_ prefix to define our own semantic.
>>
> It seems good to do both
> use fmax*/fmin* to support NaN handling
> and add av_* (probably av_max*/av_min*) to make it more consistent
> with av_clip*/etc
If a function with side-effects is used inside FFMIN/FFMAX, thats a
simple bug and should be fixed.
We don't need to introduce new functions for that. av_clip* exists
because they are quite a bit more complex than min/max, and even have
architecture specific optimized versions in some cases.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Tue, Nov 3, 2015 at 11:10 AM, Muhammad Faiz wrote:
> On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote:
>> On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote:
>>> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
>>> > On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer
>>> > wrote:
>>> > > From: Michael Niedermayer
>>> > >
>>> > > This should fix the build failure of avf_showcqt.c
>>> > >
>>> > > An alternative solution would be to add a check for fmin/fmax to
>>> > > fate-source and
>>> > > then to replace them by FFMIN/FFMAX, i can do that if preferred?
>>> > >
>>> > > Untested due to lack of a affected platform
>>> > >
>>> > > Signed-off-by: Michael Niedermayer
>>> > > ---
>>> > > configure|8
>>> > > libavutil/libm.h | 28
>>> > > 2 files changed, 36 insertions(+)
>>> > >
>>> > > diff --git a/configure b/configure
>>> > > index 95790f4..e6f5d2c 100755
>>> > > --- a/configure
>>> > > +++ b/configure
>>> > > @@ -1770,6 +1770,10 @@ MATH_FUNCS="
>>> > > exp2
>>> > > exp2f
>>> > > expf
>>> > > +fmax
>>> > > +fmaxf
>>> > > +fmin
>>> > > +fminf
>>> > > isinf
>>> > > isnan
>>> > > ldexpf
>>> > > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
>>> > > disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h
>>> > > DtsCrystalHDVersion -lcrystalhd || disable crystalhd
>>> > >
>>> > > atan2f_args=2
>>> > > +fmax_args=2
>>> > > +fmaxf_args=2
>>> > > +fmin_args=2
>>> > > +fminf_args=2
>>> > > copysign_args=2
>>> > > ldexpf_args=2
>>> > > powf_args=2
>>> > > diff --git a/libavutil/libm.h b/libavutil/libm.h
>>> > > index 6c17b28..ba837a2 100644
>>> > > --- a/libavutil/libm.h
>>> > > +++ b/libavutil/libm.h
>>> > > @@ -43,6 +43,34 @@
>>> > > #define atan2f(y, x) ((float)atan2(y, x))
>>> > > #endif
>>> > >
>>> > > +#if !HAVE_FMAX
>>> > > +#undef fmax
>>> > > +static av_always_inline double fmax(double x, double y)
>>> > > +{
>>> > > +if (x < y) return y;
>>> > > +else return x;
>>> > > +}
>>> > > +#endif
>>> > > +
>>> > > +#if !HAVE_FMIN
>>> > > +#undef fmin
>>> > > +static av_always_inline double fmin(double x, double y)
>>> > > +{
>>> > > +if (x < y) return x;
>>> > > +else return y;
>>> > > +}
>>> > > +#endif
>>> >
>>> > Wasn't there a concern that these emulations don't behave identical to
>>> > the C library versions in regards to NaN handling?
>>> > I faintly remember something in the previous discussion.
>>>
>>> yes, i forgot about that :(
>>> i replaced them by FFMIN / FFMAX
>>>
>>
>> Sorry to raise this again but i htink it must handle NaN, or we need to
>> use a av_ prefix to define our own semantic.
>>
> It seems good to do both
> use fmax*/fmin* to support NaN handling
> and add av_* (probably av_max*/av_min*) to make it more consistent
> with av_clip*/etc
Why av_max, av_min? fmax/fmin handle NaN. The way I see it, we need two things:
1. Floating point max/min handling NaN - fmax/fmin do the trick. They
are not always available, so we need some layers/ifdefry to ensure
fmin/fmax can be used by the project. av_max, av_min are completely
unnecessary in my view.
2. Floating point max/min not handling NaN - existing FFMIN, FFMAX do the trick.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote:
> On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote:
>> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
>> > On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer
>> > wrote:
>> > > From: Michael Niedermayer
>> > >
>> > > This should fix the build failure of avf_showcqt.c
>> > >
>> > > An alternative solution would be to add a check for fmin/fmax to
>> > > fate-source and
>> > > then to replace them by FFMIN/FFMAX, i can do that if preferred?
>> > >
>> > > Untested due to lack of a affected platform
>> > >
>> > > Signed-off-by: Michael Niedermayer
>> > > ---
>> > > configure|8
>> > > libavutil/libm.h | 28
>> > > 2 files changed, 36 insertions(+)
>> > >
>> > > diff --git a/configure b/configure
>> > > index 95790f4..e6f5d2c 100755
>> > > --- a/configure
>> > > +++ b/configure
>> > > @@ -1770,6 +1770,10 @@ MATH_FUNCS="
>> > > exp2
>> > > exp2f
>> > > expf
>> > > +fmax
>> > > +fmaxf
>> > > +fmin
>> > > +fminf
>> > > isinf
>> > > isnan
>> > > ldexpf
>> > > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
>> > > disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h
>> > > DtsCrystalHDVersion -lcrystalhd || disable crystalhd
>> > >
>> > > atan2f_args=2
>> > > +fmax_args=2
>> > > +fmaxf_args=2
>> > > +fmin_args=2
>> > > +fminf_args=2
>> > > copysign_args=2
>> > > ldexpf_args=2
>> > > powf_args=2
>> > > diff --git a/libavutil/libm.h b/libavutil/libm.h
>> > > index 6c17b28..ba837a2 100644
>> > > --- a/libavutil/libm.h
>> > > +++ b/libavutil/libm.h
>> > > @@ -43,6 +43,34 @@
>> > > #define atan2f(y, x) ((float)atan2(y, x))
>> > > #endif
>> > >
>> > > +#if !HAVE_FMAX
>> > > +#undef fmax
>> > > +static av_always_inline double fmax(double x, double y)
>> > > +{
>> > > +if (x < y) return y;
>> > > +else return x;
>> > > +}
>> > > +#endif
>> > > +
>> > > +#if !HAVE_FMIN
>> > > +#undef fmin
>> > > +static av_always_inline double fmin(double x, double y)
>> > > +{
>> > > +if (x < y) return x;
>> > > +else return y;
>> > > +}
>> > > +#endif
>> >
>> > Wasn't there a concern that these emulations don't behave identical to
>> > the C library versions in regards to NaN handling?
>> > I faintly remember something in the previous discussion.
>>
>> yes, i forgot about that :(
>> i replaced them by FFMIN / FFMAX
>>
>
> Sorry to raise this again but i htink it must handle NaN, or we need to
> use a av_ prefix to define our own semantic.
>
It seems good to do both
use fmax*/fmin* to support NaN handling
and add av_* (probably av_max*/av_min*) to make it more consistent
with av_clip*/etc
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Tue, Nov 03, 2015 at 02:42:55PM +0100, Clément Bœsch wrote: [...] > > > Wasn't there a concern that these emulations don't behave identical to > > > the C library versions in regards to NaN handling? > > > I faintly remember something in the previous discussion. > > > > yes, i forgot about that :( > > i replaced them by FFMIN / FFMAX > > > > Sorry to raise this again but i htink it must handle NaN, or we need to > use a av_ prefix to define our own semantic. > Derp. it was mentioned just above. Forget this. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote:
> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
> > On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer
> > wrote:
> > > From: Michael Niedermayer
> > >
> > > This should fix the build failure of avf_showcqt.c
> > >
> > > An alternative solution would be to add a check for fmin/fmax to
> > > fate-source and
> > > then to replace them by FFMIN/FFMAX, i can do that if preferred?
> > >
> > > Untested due to lack of a affected platform
> > >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > configure|8
> > > libavutil/libm.h | 28
> > > 2 files changed, 36 insertions(+)
> > >
> > > diff --git a/configure b/configure
> > > index 95790f4..e6f5d2c 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -1770,6 +1770,10 @@ MATH_FUNCS="
> > > exp2
> > > exp2f
> > > expf
> > > +fmax
> > > +fmaxf
> > > +fmin
> > > +fminf
> > > isinf
> > > isnan
> > > ldexpf
> > > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
> > > disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h
> > > DtsCrystalHDVersion -lcrystalhd || disable crystalhd
> > >
> > > atan2f_args=2
> > > +fmax_args=2
> > > +fmaxf_args=2
> > > +fmin_args=2
> > > +fminf_args=2
> > > copysign_args=2
> > > ldexpf_args=2
> > > powf_args=2
> > > diff --git a/libavutil/libm.h b/libavutil/libm.h
> > > index 6c17b28..ba837a2 100644
> > > --- a/libavutil/libm.h
> > > +++ b/libavutil/libm.h
> > > @@ -43,6 +43,34 @@
> > > #define atan2f(y, x) ((float)atan2(y, x))
> > > #endif
> > >
> > > +#if !HAVE_FMAX
> > > +#undef fmax
> > > +static av_always_inline double fmax(double x, double y)
> > > +{
> > > +if (x < y) return y;
> > > +else return x;
> > > +}
> > > +#endif
> > > +
> > > +#if !HAVE_FMIN
> > > +#undef fmin
> > > +static av_always_inline double fmin(double x, double y)
> > > +{
> > > +if (x < y) return x;
> > > +else return y;
> > > +}
> > > +#endif
> >
> > Wasn't there a concern that these emulations don't behave identical to
> > the C library versions in regards to NaN handling?
> > I faintly remember something in the previous discussion.
>
> yes, i forgot about that :(
> i replaced them by FFMIN / FFMAX
>
Sorry to raise this again but i htink it must handle NaN, or we need to
use a av_ prefix to define our own semantic.
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz wrote: > On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde wrote: >> On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer >> wrote: >>> On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote: On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer wrote: > From: Michael Niedermayer > > This should fix the build failure of avf_showcqt.c > > An alternative solution would be to add a check for fmin/fmax to > fate-source and > then to replace them by FFMIN/FFMAX, i can do that if preferred? > > Untested due to lack of a affected platform I recall some interest on my end to get fmin, fmax etc for different reasons, and it was remarked that commit 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary seems to be that getting it to work on all platforms is not so simple. >>> >>> :/ >>> ill replace the problematic ones by FFMIN/MAX for now so the build >>> failure on the affected msvc platforms is fixed >>> tieing a build fix to this complexity would be unwise >>> >>> I am definitely interested in getting it to work in order to replace FFMAX/FFMIN for floating point in especially libavfilter. This will allow better nan signalling at a slight performance cost. >>> >>> would that performance cost affect all systems or just ones not >>> having fmin/fmax ? >>> i think affecting all systems would be bad >> >> A correct fmin and fmax will be slower than FFMIN/FFMAX, simply >> because they do NaN handling. How much slower, I have not tested. Also >> note that flags may be passed to the compiler to ignore NaN's, >> something which can possibly be done locally if desired. However, I >> view FFMAX/FFMIN as the cleaner solution if NaN signalling/propagation >> is not an issue, so I may not pursue this. >> > > Common problem with FFMIN/FFMAX (and other macros that evaluates > arguments more than once): > FFMAX(a, myfunc(b)) > will call myfunc twice (OK compiler may optimize it and call myfunc once) > and often people don't care about it. That goes without saying, but sometimes compiler can't optimize due to sequence point stuff. This is why the macro should be used cautiously. However, FFmpeg devs are generally cautious about these things so I no longer press this that hard. The real technical benefit (if any) is the different NaN handling as noted above. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde wrote: > On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer > wrote: >> On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote: >>> On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer >>> wrote: >>> > From: Michael Niedermayer >>> > >>> > This should fix the build failure of avf_showcqt.c >>> > >>> > An alternative solution would be to add a check for fmin/fmax to >>> > fate-source and >>> > then to replace them by FFMIN/FFMAX, i can do that if preferred? >>> > >>> > Untested due to lack of a affected platform >>> >>> I recall some interest on my end to get fmin, fmax etc for different >>> reasons, and it was remarked that commit >>> 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary >>> seems to be that getting it to work on all platforms is not so simple. >> >> :/ >> ill replace the problematic ones by FFMIN/MAX for now so the build >> failure on the affected msvc platforms is fixed >> tieing a build fix to this complexity would be unwise >> >> >>> I am definitely interested in getting it to work in order to replace >>> FFMAX/FFMIN for floating point in especially libavfilter. This will >>> allow better nan signalling at a slight performance cost. >> >> would that performance cost affect all systems or just ones not >> having fmin/fmax ? >> i think affecting all systems would be bad > > A correct fmin and fmax will be slower than FFMIN/FFMAX, simply > because they do NaN handling. How much slower, I have not tested. Also > note that flags may be passed to the compiler to ignore NaN's, > something which can possibly be done locally if desired. However, I > view FFMAX/FFMIN as the cleaner solution if NaN signalling/propagation > is not an issue, so I may not pursue this. > Common problem with FFMIN/FFMAX (and other macros that evaluates arguments more than once): FFMAX(a, myfunc(b)) will call myfunc twice (OK compiler may optimize it and call myfunc once) and often people don't care about it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer wrote: > On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote: >> On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer >> wrote: >> > From: Michael Niedermayer >> > >> > This should fix the build failure of avf_showcqt.c >> > >> > An alternative solution would be to add a check for fmin/fmax to >> > fate-source and >> > then to replace them by FFMIN/FFMAX, i can do that if preferred? >> > >> > Untested due to lack of a affected platform >> >> I recall some interest on my end to get fmin, fmax etc for different >> reasons, and it was remarked that commit >> 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary >> seems to be that getting it to work on all platforms is not so simple. > > :/ > ill replace the problematic ones by FFMIN/MAX for now so the build > failure on the affected msvc platforms is fixed > tieing a build fix to this complexity would be unwise > > >> I am definitely interested in getting it to work in order to replace >> FFMAX/FFMIN for floating point in especially libavfilter. This will >> allow better nan signalling at a slight performance cost. > > would that performance cost affect all systems or just ones not > having fmin/fmax ? > i think affecting all systems would be bad A correct fmin and fmax will be slower than FFMIN/FFMAX, simply because they do NaN handling. How much slower, I have not tested. Also note that flags may be passed to the compiler to ignore NaN's, something which can possibly be done locally if desired. However, I view FFMAX/FFMIN as the cleaner solution if NaN signalling/propagation is not an issue, so I may not pursue this. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many things microsoft did are stupid, but not doing something just because > microsoft did it is even more stupid. If everything ms did were stupid they > would be bankrupt already. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Fri, Oct 30, 2015 at 7:33 PM, Michael Niedermayer
wrote:
> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
>> On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer
>> wrote:
>> > From: Michael Niedermayer
>> >
>> > This should fix the build failure of avf_showcqt.c
>> >
>> > An alternative solution would be to add a check for fmin/fmax to
>> > fate-source and
>> > then to replace them by FFMIN/FFMAX, i can do that if preferred?
>> >
>> > Untested due to lack of a affected platform
>> >
>> > Signed-off-by: Michael Niedermayer
>> > ---
>> > configure|8
>> > libavutil/libm.h | 28
>> > 2 files changed, 36 insertions(+)
>> >
>> > diff --git a/configure b/configure
>> > index 95790f4..e6f5d2c 100755
>> > --- a/configure
>> > +++ b/configure
>> > @@ -1770,6 +1770,10 @@ MATH_FUNCS="
>> > exp2
>> > exp2f
>> > expf
>> > +fmax
>> > +fmaxf
>> > +fmin
>> > +fminf
>> > isinf
>> > isnan
>> > ldexpf
>> > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
>> > disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h
>> > DtsCrystalHDVersion -lcrystalhd || disable crystalhd
>> >
>> > atan2f_args=2
>> > +fmax_args=2
>> > +fmaxf_args=2
>> > +fmin_args=2
>> > +fminf_args=2
>> > copysign_args=2
>> > ldexpf_args=2
>> > powf_args=2
>> > diff --git a/libavutil/libm.h b/libavutil/libm.h
>> > index 6c17b28..ba837a2 100644
>> > --- a/libavutil/libm.h
>> > +++ b/libavutil/libm.h
>> > @@ -43,6 +43,34 @@
>> > #define atan2f(y, x) ((float)atan2(y, x))
>> > #endif
>> >
>> > +#if !HAVE_FMAX
>> > +#undef fmax
>> > +static av_always_inline double fmax(double x, double y)
>> > +{
>> > +if (x < y) return y;
>> > +else return x;
>> > +}
>> > +#endif
>> > +
>> > +#if !HAVE_FMIN
>> > +#undef fmin
>> > +static av_always_inline double fmin(double x, double y)
>> > +{
>> > +if (x < y) return x;
>> > +else return y;
>> > +}
>> > +#endif
>>
>> Wasn't there a concern that these emulations don't behave identical to
>> the C library versions in regards to NaN handling?
>> I faintly remember something in the previous discussion.
>
> yes, i forgot about that :(
> i replaced them by FFMIN / FFMAX
I might be missing your exact usage of FFMIN/FFMAX, but note
FFMIN/FFMAX by themselves do not do any NaN handling. Maybe this
confusion will be clarified when you post v2. Ideas of achieving this
may be easily obtained in the commit I mentioned above:
4436a8f44dedc83767b3d9da9beb85d1fae2ca30.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
> On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer
> wrote:
> > From: Michael Niedermayer
> >
> > This should fix the build failure of avf_showcqt.c
> >
> > An alternative solution would be to add a check for fmin/fmax to
> > fate-source and
> > then to replace them by FFMIN/FFMAX, i can do that if preferred?
> >
> > Untested due to lack of a affected platform
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > configure|8
> > libavutil/libm.h | 28
> > 2 files changed, 36 insertions(+)
> >
> > diff --git a/configure b/configure
> > index 95790f4..e6f5d2c 100755
> > --- a/configure
> > +++ b/configure
> > @@ -1770,6 +1770,10 @@ MATH_FUNCS="
> > exp2
> > exp2f
> > expf
> > +fmax
> > +fmaxf
> > +fmin
> > +fminf
> > isinf
> > isnan
> > ldexpf
> > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
> > disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h
> > DtsCrystalHDVersion -lcrystalhd || disable crystalhd
> >
> > atan2f_args=2
> > +fmax_args=2
> > +fmaxf_args=2
> > +fmin_args=2
> > +fminf_args=2
> > copysign_args=2
> > ldexpf_args=2
> > powf_args=2
> > diff --git a/libavutil/libm.h b/libavutil/libm.h
> > index 6c17b28..ba837a2 100644
> > --- a/libavutil/libm.h
> > +++ b/libavutil/libm.h
> > @@ -43,6 +43,34 @@
> > #define atan2f(y, x) ((float)atan2(y, x))
> > #endif
> >
> > +#if !HAVE_FMAX
> > +#undef fmax
> > +static av_always_inline double fmax(double x, double y)
> > +{
> > +if (x < y) return y;
> > +else return x;
> > +}
> > +#endif
> > +
> > +#if !HAVE_FMIN
> > +#undef fmin
> > +static av_always_inline double fmin(double x, double y)
> > +{
> > +if (x < y) return x;
> > +else return y;
> > +}
> > +#endif
>
> Wasn't there a concern that these emulations don't behave identical to
> the C library versions in regards to NaN handling?
> I faintly remember something in the previous discussion.
yes, i forgot about that :(
i replaced them by FFMIN / FFMAX
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote: > On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer wrote: > > From: Michael Niedermayer > > > > This should fix the build failure of avf_showcqt.c > > > > An alternative solution would be to add a check for fmin/fmax to > > fate-source and > > then to replace them by FFMIN/FFMAX, i can do that if preferred? > > > > Untested due to lack of a affected platform > > I recall some interest on my end to get fmin, fmax etc for different > reasons, and it was remarked that commit > 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary > seems to be that getting it to work on all platforms is not so simple. :/ ill replace the problematic ones by FFMIN/MAX for now so the build failure on the affected msvc platforms is fixed tieing a build fix to this complexity would be unwise > I am definitely interested in getting it to work in order to replace > FFMAX/FFMIN for floating point in especially libavfilter. This will > allow better nan signalling at a slight performance cost. would that performance cost affect all systems or just ones not having fmin/fmax ? i think affecting all systems would be bad [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> This should fix the build failure of avf_showcqt.c
>
> An alternative solution would be to add a check for fmin/fmax to fate-source
> and
> then to replace them by FFMIN/FFMAX, i can do that if preferred?
>
> Untested due to lack of a affected platform
>
> Signed-off-by: Michael Niedermayer
> ---
> configure|8
> libavutil/libm.h | 28
> 2 files changed, 36 insertions(+)
>
> diff --git a/configure b/configure
> index 95790f4..e6f5d2c 100755
> --- a/configure
> +++ b/configure
> @@ -1770,6 +1770,10 @@ MATH_FUNCS="
> exp2
> exp2f
> expf
> +fmax
> +fmaxf
> +fmin
> +fminf
> isinf
> isnan
> ldexpf
> @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
> disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h
> DtsCrystalHDVersion -lcrystalhd || disable crystalhd
>
> atan2f_args=2
> +fmax_args=2
> +fmaxf_args=2
> +fmin_args=2
> +fminf_args=2
> copysign_args=2
> ldexpf_args=2
> powf_args=2
> diff --git a/libavutil/libm.h b/libavutil/libm.h
> index 6c17b28..ba837a2 100644
> --- a/libavutil/libm.h
> +++ b/libavutil/libm.h
> @@ -43,6 +43,34 @@
> #define atan2f(y, x) ((float)atan2(y, x))
> #endif
>
> +#if !HAVE_FMAX
> +#undef fmax
> +static av_always_inline double fmax(double x, double y)
> +{
> +if (x < y) return y;
> +else return x;
> +}
> +#endif
> +
> +#if !HAVE_FMIN
> +#undef fmin
> +static av_always_inline double fmin(double x, double y)
> +{
> +if (x < y) return x;
> +else return y;
> +}
> +#endif
Wasn't there a concern that these emulations don't behave identical to
the C library versions in regards to NaN handling?
I faintly remember something in the previous discussion.
> +
> +#if !HAVE_FMAXF
> +#undef fmaxf
> +#define fmaxf(y, x) ((float)fmax(y, x))
> +#endif
> +
> +#if !HAVE_FMINF
> +#undef fminf
> +#define fminf(y, x) ((float)fmin(y, x))
> +#endif
> +
> #if !HAVE_POWF
> #undef powf
> #define powf(x, y) ((float)pow(x, y))
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> This should fix the build failure of avf_showcqt.c
>
> An alternative solution would be to add a check for fmin/fmax to fate-source
> and
> then to replace them by FFMIN/FFMAX, i can do that if preferred?
>
> Untested due to lack of a affected platform
I recall some interest on my end to get fmin, fmax etc for different
reasons, and it was remarked that commit
4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary
seems to be that getting it to work on all platforms is not so simple.
I am definitely interested in getting it to work in order to replace
FFMAX/FFMIN for floating point in especially libavfilter. This will
allow better nan signalling at a slight performance cost.
>
> Signed-off-by: Michael Niedermayer
> ---
> configure|8
> libavutil/libm.h | 28
> 2 files changed, 36 insertions(+)
>
> diff --git a/configure b/configure
> index 95790f4..e6f5d2c 100755
> --- a/configure
> +++ b/configure
> @@ -1770,6 +1770,10 @@ MATH_FUNCS="
> exp2
> exp2f
> expf
> +fmax
> +fmaxf
> +fmin
> +fminf
> isinf
> isnan
> ldexpf
> @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
> disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h
> DtsCrystalHDVersion -lcrystalhd || disable crystalhd
>
> atan2f_args=2
> +fmax_args=2
> +fmaxf_args=2
> +fmin_args=2
> +fminf_args=2
> copysign_args=2
> ldexpf_args=2
> powf_args=2
> diff --git a/libavutil/libm.h b/libavutil/libm.h
> index 6c17b28..ba837a2 100644
> --- a/libavutil/libm.h
> +++ b/libavutil/libm.h
> @@ -43,6 +43,34 @@
> #define atan2f(y, x) ((float)atan2(y, x))
> #endif
>
> +#if !HAVE_FMAX
> +#undef fmax
> +static av_always_inline double fmax(double x, double y)
> +{
> +if (x < y) return y;
> +else return x;
> +}
> +#endif
> +
> +#if !HAVE_FMIN
> +#undef fmin
> +static av_always_inline double fmin(double x, double y)
> +{
> +if (x < y) return x;
> +else return y;
> +}
> +#endif
> +
> +#if !HAVE_FMAXF
> +#undef fmaxf
> +#define fmaxf(y, x) ((float)fmax(y, x))
> +#endif
> +
> +#if !HAVE_FMINF
> +#undef fminf
> +#define fminf(y, x) ((float)fmin(y, x))
> +#endif
> +
> #if !HAVE_POWF
> #undef powf
> #define powf(x, y) ((float)pow(x, y))
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
From: Michael Niedermayer
This should fix the build failure of avf_showcqt.c
An alternative solution would be to add a check for fmin/fmax to fate-source and
then to replace them by FFMIN/FFMAX, i can do that if preferred?
Untested due to lack of a affected platform
Signed-off-by: Michael Niedermayer
---
configure|8
libavutil/libm.h | 28
2 files changed, 36 insertions(+)
diff --git a/configure b/configure
index 95790f4..e6f5d2c 100755
--- a/configure
+++ b/configure
@@ -1770,6 +1770,10 @@ MATH_FUNCS="
exp2
exp2f
expf
+fmax
+fmaxf
+fmin
+fminf
isinf
isnan
ldexpf
@@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h
DtsCrystalHDVersion -lcrystalhd || disable crystalhd
atan2f_args=2
+fmax_args=2
+fmaxf_args=2
+fmin_args=2
+fminf_args=2
copysign_args=2
ldexpf_args=2
powf_args=2
diff --git a/libavutil/libm.h b/libavutil/libm.h
index 6c17b28..ba837a2 100644
--- a/libavutil/libm.h
+++ b/libavutil/libm.h
@@ -43,6 +43,34 @@
#define atan2f(y, x) ((float)atan2(y, x))
#endif
+#if !HAVE_FMAX
+#undef fmax
+static av_always_inline double fmax(double x, double y)
+{
+if (x < y) return y;
+else return x;
+}
+#endif
+
+#if !HAVE_FMIN
+#undef fmin
+static av_always_inline double fmin(double x, double y)
+{
+if (x < y) return x;
+else return y;
+}
+#endif
+
+#if !HAVE_FMAXF
+#undef fmaxf
+#define fmaxf(y, x) ((float)fmax(y, x))
+#endif
+
+#if !HAVE_FMINF
+#undef fminf
+#define fminf(y, x) ((float)fmin(y, x))
+#endif
+
#if !HAVE_POWF
#undef powf
#define powf(x, y) ((float)pow(x, y))
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
