Hi On Mon, Oct 06, 2014 at 10:40:51AM +0000, Nedeljko Babic wrote: > Hi and sorry for such a late response. > > It looks that I misplaced this mail... > > > From: Djordje Pesut <djordje.pe...@imgtec.com> > >> > >> Add float emulation > >> > >> Signed-off-by: Nedeljko Babic <nedeljko.ba...@imgtec.com> > >> --- > >> libavcodec/float_emu.h | 295 > >> +++++++++++++++++++++++++++++++++++++++++++++ > >> libavcodec/float_emu_tab.c | 293 > >> ++++++++++++++++++++++++++++++++++++++++++++ > >> 2 files changed, 588 insertions(+) > >> create mode 100644 libavcodec/float_emu.h > >> create mode 100644 libavcodec/float_emu_tab.c > > > >theres libavutil/softfloat > > > >I dont see why this should be re implemented in each decoder > >If you can improve softfloat, please do > > > >[...] > > > > If I am not mistaking, there is one (possibly two) more implementations of > float emulation besides softfloat in ffmpeg (dca encoder and lagarith > decoder),
lagarith is a lossless codec, it needs a "bitexact to the reference" implementation, so it cannot easily be shared > but I do agree that it is more maintainable to have one float emulation and I > am willing to integrate our emulation in softfloat. > > However, there is a difference in some conventions used (for example is it > more > important to represent exactly 0.5 or 1, order of fields in struct that > represents emulated float, etc.) and our aac implementation is tailored to use > our float emulation. i dont understand what you mean by 0.5 vs 1 ? floats are base 2 so both 0.5 and 1 can be represented exactly > > Could I assume that in such cases I can change convention that is used in > softfloat with convection that we use, since I don't see that softfloat is > used > anywhere in ffmpeg currently? > > That way we could integrate our code without need to change aac implementation > and without need for changes in parts of float emulation that are not > supported > in softfloat currently (sqrt and sincos). > > Also, there is a question that Reimar initiated in his review of whether it's > more important to optimize the case where an operand is 0 or to reduce the > number of branches. this is hard to awnser without having code in place that uses the softfloat stuff so that we are able to benchmark but id say if the cost for a 0 check is very small and its gain are very big then its likely a good idea also theres the question why add/mul would be called with trivial arguments, this is potentially a sign that the calling code is poorly written and performs avoidable operations [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
