[XviD-devel] New Qpel code

[Michael Militzer]

Quoting Edouard Gomez <ed.gomez at free.fr>:

> Michael Militzer (michael at xvid.org) wrote:
> > well, it's mmx code and c code imitating the mmx behaviour (so it's a c
> > reference implementation for the mmx code). On MMX machines, the mmx asm
> > code is used and this gives an improvement. However the new c code
> (qpel.c)
> > is much slower than the already available c code (interpolate8x8.c). This
> > should be true for all platforms - I haven't tested it on any platform
> > besides x86, but I would be very very surprised if the new c code would
> > be faster on any other platform.
> 
> That's what i thought, the C  code is completly useless (well, it's here
> for reference,  i would not  call that useless  ;-). It's just  that for
> portability tracking it would be much better if we merged both codes. It
> just means as far as my undertsanding of the new code goes) that we must
> group  calls to  transfer8x8, interpolate_xxxx  functions  into wrappers
> that we could simply bind into XVID_QP_FUNCS. 

Or we could make interpolate16x16_qpel a function pointer and set it to
either new or old interpolate code depending whether MMX is available or
not. However I'm not sure if this is really needed. Someone who uses IA32
without MMX, but wants qpel should be punished for trying ;-)

> > > PS:  i'll commit  some cleanups  for this  new code  in order  1/  to be
> > > CodingStyle compliant  and 2/ to make  it build on unix  and/or non ia32
> > > correctly.
> > 
> > It doesn't build on unix?
> 
> It _did_  not build  because you did  not update the  sources definition
> (you  can't know  that as  you  use the  MSVC project  files, so  you're
> forgiven  ;-) And  when  i  saw a  init_QP_mmx()  call w/o  architecture
> checking,  i feared  it would  break other  archs... i  just  added some
> #ifdef  to  the   code  just  to  be  sure.  Only   a  couple  of  minor
> changes... nothing to worry. 

init_QP_mmx just initialises some tables. It shouldn't be a problem for
other architectures. Also the c code needs these tables as well (iirc).

> Btw it seems it doesn't build well with crappy MS .net compilers :-P see
> the bug  report in a previous mail  from a user (.NET  compiler does not
> expand __FILE__ in an #include preprocessor directive)

.NET is crap. But it's strange that the code compiles with VC 6, but does
not with VC 7. Isn't there a VC 6 compatibility mode in .NET?

bye,
Michael