[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