[XviD-devel] New Qpel code

Edouard Gomez ed.gomez at free.fr
Sat Aug 23 20:50:28 CEST 2003


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. 

That's just not to have to track changes in new_interpolate and old code
for different platforms.

 
> > 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. 

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)

-- 
Edouard Gomez


More information about the XviD-devel mailing list