[FFmpeg-devel] [PATCH] Fast half-float to float conversion

[Reimar Döffinger]

On Tue, Jun 30, 2009 at 03:56:32PM +0200, Jimmy Christensen wrote:
> On 2009-06-30 15:50, Reimar D?ffinger wrote:
> > On Tue, Jun 30, 2009 at 03:09:33PM +0200, Jimmy Christensen wrote:
> >>> Lastly it seems to me that this code would belong into
> >>> libavutil/intfloat_readwrite.*
> >>
> >> You are probably right.
> >
> > Personally I'd suggest doing a stupid implementation for
> > libavutil/intfloat_readwrite.*, something like this (certainly
> > not a beauty, possibly buggy, does not support denormals, though since
> > they are rare it probably wouldn't be a big issue to add handling for
> > them in if (nosign<  0x0400)).
> > float av_int2halflt(int16_t v){
> >      uint16_t nosign = v+v;
> >      if (nosign>= 0xfc00) {
> >          if (nosign == 0xfc00) return v>>15 ? -1.0/0.0 : 1.0/0.0;
> >          else return 0.0/0.0;
> >      }
> >      if (nosign<  0x0400) return 0; // denormal or 0
> >      return ldexp((v&0x3ff) + (1<<11)) * (v>>15|1), (v>>10&0x1f)-26);
> > }
> >
> >
> > And consider an optimized version only after it is actually used and
> > thus it is clear what kind of optimizations are necessary/most useful.
> > E.g. the table based approach probably is hard to SIMD and thus might be
> > a bad idea if you want to convert a lot of data.
> 
> So I should just put the table into the OpenEXR decoder (eg. disabled by 
> default)?

No, you shouldn't add it at all unless you really need it.
Personally I don't think there is any need for such optimization for the
first implementation of such a rare format as OpenEXR, it can still be
added after the rest has passed review (though Michael sometimes has a
different opinion on these kinds of things), and hopefully in a way that can
be properly optimized with assembly (whether ARM NEON or SSE2 or
whatever).