[XviD-devel] Profilign XVID, Part II

[Jim Hauxwell]

One thing that will probably speed up the transfer8x8_copy is different
versions depending on the alignment of the src.

This routine should always have an aligned destintion, but missaligned src.
You don't tend to notice this on x86 as the core supports missaligned
loads/stores, but you pay a high penalty for them.  On a decoder I wrote I
found that it was quicker to test the alignment an call the correct copy
routine. eg

32bit aligned
load32
load32

16bit aligned
load16
load32
load16

and so on.

May not make a difference here, but then again it might.

Jim



> -----Original Message-----
> From: xvid-devel-bounces at xvid.org [mailto:xvid-devel-bounces at xvid.org]On
> Behalf Of Michael Militzer
> Sent: 01 March 2003 17:12
> To: xvid-devel at xvid.org
> Subject: Re: [XviD-devel] Profilign XVID, Part II
>
>
> Hi,
>
> Quoting Christoph Lampert <chl at math.uni-bonn.de>:
>
> > Hi, now the decoding part:
> >
> > Without Qpel, MMX and XMM are rather similar:
> > yv12_to_yv12 and transfer8x8_copy dominate
> >
> > GOAL 4)  _again_ try to sqeeze the last out of  yv12_to_yv12
> >          and transfer-functions.
>
> again: forget it. Memory transfers are unfortunately even more
> dominant for
> decoding than for encoding. And you have just profiled decoding with yv12
> output. Just try the same for rgb output: rgb conversion needs
> more time than
> the whole decoding process...
>
> ok, you can now conclude that our colorspace transformations are
> slow. However
> I'd rather say that our decoder is just damn fast ;-)
>
> > With QPel, it's the interpolation again.
> >
> > GOAL 5) _again_ try to create (partial?) SIMD version of
> >         interpolate16x16_lowpass_v_c
> >         interpolate16x16_lowpass_h_c
> >         interpolate8x8_lowpass_v_c
> >         interpolate8x8_lowpass_h_c
> >
> >
> > It seems that with those we would optimize encoder and decoder
> at the same
> > time, a rare opportunity.
>
> Same thing: there should be asmed code for all of these. Don't
> know what's
> wrong here, but I'll have a look...
>
> bye,
> Michael
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel