[FFmpeg-devel] MPEG-2 Acceleration Refactor
Michael Niedermayer
michaelni
Fri Jun 22 09:50:48 CEST 2007
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>
More information about the ffmpeg-devel
mailing list