[FFmpeg-devel] [PATCH] RV40 Decoder - 2/3 - MC functions

[Michael Niedermayer]

On Mon, Dec 01, 2008 at 08:56:07AM +0200, Kostya wrote:
> On Sun, Nov 30, 2008 at 08:01:51PM +0100, Michael Niedermayer wrote:
> > On Sun, Nov 30, 2008 at 08:07:15PM +0200, Kostya wrote:
> > > On Sun, Nov 30, 2008 at 06:01:50PM +0100, Michael Niedermayer wrote:
> > > [...]
> > > > > 
> > > > > That will work in these cases:
> > > > > 1. I move RV40 luma MC to dsputil.c (not a good idea IMO)
> > > > > 2. Make {put,avg}_pixels_xy2_c() non-static (not a good idea either)
> > > > > 3. Initialize DSPContext inside function and call that function (ineffective)
> > > > 
> > > > what about
> > > > func(abc) being in dsputil.c (where {put,avg}_pixels_xy2_c() is) and setting
> > > > mc33 from there too, while leaving the others in rv40 specific files?
> > > 
> > > here
> > 
> > ugly but ok
> 
> applied
> 
> > as ive no idea ATM how to simplify it cleanly (what i mean with
> > simplify here would be
> > 1. merging it with h264 at source level
> > 2. maybe trying some other system than having 1 function per each of the 16
> >    cases (this also applies to h.264)
> 
> We have case 2 for H.264 and RV40 chroma MC currently.
> IMO RV40 is not that important to slow down H.264 because of it.

you misunderstand, having 16 functions puts a lot of pressure on the code
cache and calls through function pointers are not as well predicted as
conditional branches, a different implementation for h264 may very well be
faster.
That being an idea to try and benchmark of course not something that should
be done blindly ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081201/16be008c/attachment.pgp>