[FFmpeg-devel] Possible cache use improvements

Michael Niedermayer michaelni
Sun Aug 10 21:37:26 CEST 2008


On Sun, Aug 10, 2008 at 09:34:25PM +0300, Uoti Urpala wrote:
> I wondered why using direct rendering in MPlayer gave no performance
> improvement, even when testing with a large mpeg2 video where the
> relative extra cost of copying should be significant. I determined that
> the most probable cause was less efficient cache use by libavcodec in
> the direct rendering case. When *not* using direct rendering, libavcodec
> draws each macroblock row of B frames into the same area, then gives the
> slice to MPlayer which copies it with fastmemcpy to its final
> destination. When using direct rendering libavcodec decodes each
> macroblock row directly to its real position in the frame. It seems that
> always decoding a row to the same area and then copying with fastmemcpy
> to the final destination is better than decoding directly to the final
> destination (which is unlikely to be in cache).
> 
> The attached patch gave a more than 5% performance improvement in the
> _overall_ CPU use of MPlayer in the test case (Athlon XP, 1280x720 mpeg2
> video, vo xv, direct rendering). It changes mpeg2 to always decode a row
> to the same place and then copy it with fastmemcpy to the real
> destination; this avoids cache misses during the decoding and avoids
> placing the picture being written in the cache (unlikely to be accessed
> again before it's evicted). This version causes some image corruption
> because it uses the top row of the image instead of a proper scratch
> area.

Its very nice to see someone pick up arpis old idea of rowwise(=slice for
mpeg2) decoding.
Once you make it actually work and if its still faster then, then iam very
interrested in this. Currently though its just 5% faster way to produce
corrupted images this is not that usefull ...

Also i do not think a scratch area will be the only thing that has to be
added t make this work. You likely will have to do something with the
mb_skip code as well.

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20080810/81f16766/attachment.pgp>



More information about the ffmpeg-devel mailing list