[FFmpeg-cvslog] fate: only check stddev for acodec-ra144

Michael Niedermayer michaelni at gmx.at
Fri Jun 1 23:13:19 CEST 2012


On Fri, Jun 01, 2012 at 06:40:31PM +0200, Reimar Döffinger wrote:
> On Fri, Jun 01, 2012 at 06:26:13PM +0200, Michael Niedermayer wrote:
> > On Fri, Jun 01, 2012 at 05:59:04PM +0200, Reimar Döffinger wrote:
> > > On Fri, Jun 01, 2012 at 12:20:25PM +0200, Michael Niedermayer wrote:
> > > > ffmpeg | branch: master | Michael Niedermayer <michaelni at gmx.at> | Thu May 31 03:08:56 2012 +0200| [e6866b1c6702aee5b696c5a49c20edb136e0427c] | committer: Michael Niedermayer
> > > > 
> > > > fate: only check stddev for acodec-ra144
> > > > 
> > > > ra144 uses floats so bitexactness cannot be guranteed
> > > > This should fix a long standing issue with icc
> > > 
> > > Not to complain, but did you investigate?
> > > The fact that all other compilers, and even ARM, x86, x86_64 using SSE,
> > > PPC,... all give exactly the same result made me suspect that there
> > > is actually something at least strange but possibly wrong either
> > > with ICC or with the code.
> > 
> > the PSNR value stays the same with the printed precission
> > the stddev value changes by 0.004% the MAXDIFF stayed the same
> > and so did the length
> 
> Yes, I saw that before.
> 
> > and IIRC icc is able to do some advanced float optimizations which
> > are enabled by default
> > above feels like consistently pointing to a minor float optimization
> > difference.
> 
> Or a big breakage in a case that didn't really matter much to the
> encoder. It just seems strange that any of those "advanced float
> optimizations" should make more of a difference than 80 bit x86 vs.
> 32 bit ARM float for example.

afaik icc will change things like a+b+c to a+c+b.
Also gcc & icc can use SSE registers (32 and 64bit) instead of the
old 80bit float stack


> This is even more relevant since we don't use -ffast-math (not even

i think the equivalent is default for ICC


> the less problematic sub-options of it) with gcc so there might be
> a bit of a question how much of the code was written/tested to handle
> that kind of optimization.
> Though maybe we should just enable gcc options like -fno-trapping-math
> -funsafe-math-optimizations and -fno-math-errno instead.

more fate instances testing more cases would be very usefull ...

anyway, what should we do about this issue here ?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-cvslog/attachments/20120601/78c324f1/attachment.asc>


More information about the ffmpeg-cvslog mailing list