[FFmpeg-devel] MPEG-2 Acceleration Refactor

[Michael Niedermayer]

Hi

On Wed, Jun 20, 2007 at 10:31:34AM -0700, Greg Hulands wrote:
> Michael Niedermayer wrote:
> >Hi
> >
> >On Tue, Jun 19, 2007 at 07:55:17PM -0700, Greg Hulands wrote:
> >  
> >[...]
> >the decode_block(..., int fast)
> >should be av_always_inline
> >if that is not slower iam fine with the patch
> >  
> Ok, av_always_inline is slower. The benchmarks are below. How do I force 
> the benchmark to use fast or slow?

-flags2 fast or something like that


> >and please name the variable fast not speed
> >  
> I've fixed that up, but won't post the patch until I can clear up the 
> av_always_inline being slower.
> >PS: whoever commits this, please redo the benchmark before commiting
> >that is benchmark with slow and fast mode, neither should get slower
> >from the patch, also look at the nm mpeg12.o output, there should be
> >no change in inlined functions (that is no new names appearing or 
> >disapearing)
> >  
> I have also attached the nm of mpeg12.o with and without the 
> av_always_inline, but not too sure how to interpret it.

sed and diff ...
the result looks like:
--- symin	2007-06-22 09:28:44.000000000 +0200
+++ syma	2007-06-22 09:28:56.000000000 +0200
@@ -7,6 +7,8 @@
          U _MPV_encode_picture
          U _MPV_frame_end
          U _MPV_frame_start
+ t _NEG_SSR32
+ t _NEG_USR32
  d ___compound_literal.0
  d ___compound_literal.1
          U ___divdi3
@@ -27,6 +29,7 @@
  s _btype2mb_type
  b _dc_chroma_vlc
  b _dc_lum_vlc
+ t _decode_dc
  t _decode_end
  t _decode_frame
  t _decode_init
@@ -58,6 +61,10 @@
          U _ff_update_duplicate_context
          U _ff_write_quant_matrix
          U _ff_zigzag_direct
+ t _get_bits
+ t _get_bits1
+ t _get_dmv
+ t _get_qscale
  t _init_2d_vlc_rl
          U _init_rl
          U _init_vlc_sparse
@@ -114,11 +121,13 @@
  s _ptype2mb_type
  d _rl_mpeg1
  d _rl_mpeg2
+ t _skip_bits1
  t _slice_decode_thread
  b _static_rl_table_store
  s _svcd_scan_offset_placeholder
  s _table_mb_btype
  s _table_mb_ptype
+ t _unaligned32_be
  b _uni_mpeg1_ac_vlc_len
  b _uni_mpeg2_ac_vlc_len
  s _vlc_dc_chroma_bits

am i correct in the assumtation that the only difference between the 2 files
is that av_always_inline is replaced by inline? (this would be the conclusion
from your claim that the split without av_always_inline does not change the
asm output)

if yes then this is a new gcc bug, that is gcc inlines fewer functions
with av_always_inline but there is not a single function it inlines in the
av_always_inline case which wasnt already inlined wthout it

if no and the normal inline case looks different then this is still a
gcc bug just not a new one, av_always_inline should IMO inline the function
without changing the inlining of the other code (if av_inline behaves
different, which it does sadly, then its not usefull for anything and
another attribute which does force the inlining of a function without
code slowification sideeffectes would be needed)

maybe you should complain to the gcc devels to either fix always inline
or provide a attribute which really inlines a function without sideeffects

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070622/806697a2/attachment.pgp>