1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
optimization Tips (for libavcodec):
===================================
What to optimize:
-----------------
If you plan to do non-x86 architecture specific optimizations (SIMD normally),
then take a look in the i386/ directory, as most important functions are
already optimized for MMX.
If you want to do x86 optimizations then you can either try to finetune the
stuff in the i386 directory or find some other functions in the C source to
optimize, but there aren't many left.
Understanding these overoptimized functions:
--------------------------------------------
As many functions tend to be a bit difficult to understand because
of optimizations, it can be hard to optimize them further, or write
architecture-specific versions. It is recommened to look at older
revisions of the interesting files (for a web frontend try ViewVC at
http://svn.mplayerhq.hu/ffmpeg/trunk/).
Alternatively, look into the other architecture-specific versions in
the i386/, ppc/, alpha/ subdirectories. Even if you don't exactly
comprehend the instructions, it could help understanding the functions
and how they can be optimized.
NOTE: If you still don't understand some function, ask at our mailing list!!!
(http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel)
What speedup justifies an optimizetion?
---------------------------------------
Normaly with clean&simple optimizations and widely used codecs a overall
speedup of the affected codec of 0.1% is enough. These speedups accumulate
and can make a big difference after a while ...
Also if none of the following gets worse and at least one gets better then an
optimization is always a good idea even if the overall gain is less than 0.1%
(speed, binary code size, source size, source readability)
For obscure codecs noone uses, the goal is more toward keeping the code clean
small and readable than to make it 1% faster.
WTF is that function good for ....:
-----------------------------------
The primary purpose of that list is to avoid wasting time to optimize functions
which are rarely used
put(_no_rnd)_pixels{,_x2,_y2,_xy2}
Used in motion compensation (en/decoding).
avg_pixels{,_x2,_y2,_xy2}
Used in motion compensation of B-frames.
These are less important than the put*pixels functions.
avg_no_rnd_pixels*
unused
pix_abs16x16{,_x2,_y2,_xy2}
Used in motion estimation (encoding) with SAD.
pix_abs8x8{,_x2,_y2,_xy2}
Used in motion estimation (encoding) with SAD of MPEG-4 4MV only.
These are less important than the pix_abs16x16* functions.
put_mspel8_mc* / wmv2_mspel8*
Used only in WMV2.
it is not recommended that you waste your time with these, as WMV2
is an ugly and relatively useless codec.
mpeg4_qpel* / *qpel_mc*
Used in MPEG-4 qpel motion compensation (encoding & decoding).
The qpel8 functions are used only for 4mv,
the avg_* functions are used only for B-frames.
Optimizing them should have a significant impact on qpel
encoding & decoding.
qpel{8,16}_mc??_old_c / *pixels{8,16}_l4
Just used to work around a bug in an old libavcodec encoder version.
Don't optimize them.
tpel_mc_func {put,avg}_tpel_pixels_tab
Used only for SVQ3, so only optimize them if you need fast SVQ3 decoding.
add_bytes/diff_bytes
For huffyuv only, optimize if you want a faster ffhuffyuv codec.
get_pixels / diff_pixels
Used for encoding, easy.
clear_blocks
easiest to optimize
gmc
Used for MPEG-4 gmc.
Optimizing this should have a significant effect on the gmc decoding
speed.
gmc1
Used for chroma blocks in MPEG-4 gmc with 1 warp point
(there are 4 luma & 2 chroma blocks per macroblock, so
only 1/3 of the gmc blocks use this, the other 2/3
use the normal put_pixel* code, but only if there is
just 1 warp point).
Note: DivX5 gmc always uses just 1 warp point.
pix_sum
Used for encoding.
hadamard8_diff / sse / sad == pix_norm1 / dct_sad / quant_psnr / rd / bit
Specific compare functions used in encoding, it depends upon the
command line switches which of these are used.
Don't waste your time with dct_sad & quant_psnr, they aren't
really useful.
put_pixels_clamped / add_pixels_clamped
Used for en/decoding in the IDCT, easy.
Note, some optimized IDCTs have the add/put clamped code included and
then put_pixels_clamped / add_pixels_clamped will be unused.
idct/fdct
idct (encoding & decoding)
fdct (encoding)
difficult to optimize
dct_quantize_trellis
Used for encoding with trellis quantization.
difficult to optimize
dct_quantize
Used for encoding.
dct_unquantize_mpeg1
Used in MPEG-1 en/decoding.
dct_unquantize_mpeg2
Used in MPEG-2 en/decoding.
dct_unquantize_h263
Used in MPEG-4/H.263 en/decoding.
FIXME remaining functions?
BTW, most of these functions are in dsputil.c/.h, some are in mpegvideo.c/.h.
Alignment:
Some instructions on some architectures have strict alignment restrictions,
for example most SSE/SSE2 instructions on x86.
The minimum guaranteed alignment is written in the .h files, for example:
void (*put_pixels_clamped)(const DCTELEM *block/*align 16*/, UINT8 *pixels/*align 8*/, int line_size);
Links:
======
http://www.aggregate.org/MAGIC/
x86-specific:
-------------
http://developer.intel.com/design/pentium4/manuals/248966.htm
The IA-32 Intel Architecture Software Developer's Manual, Volume 2:
Instruction Set Reference
http://developer.intel.com/design/pentium4/manuals/245471.htm
http://www.agner.org/assem/
AMD Athlon Processor x86 Code Optimization Guide:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf
ARM-specific:
-------------
ARM Architecture Reference Manual (up to ARMv5TE):
http://www.arm.com/community/university/eulaarmarm.html
Procedure Call Standard for the ARM Architecture:
http://www.arm.com/pdfs/aapcs.pdf
Optimization guide for ARM9E (used in Nokia 770 Internet Tablet):
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0240b/DDI0240A.pdf
Optimization guide for ARM11 (used in Nokia N800 Internet Tablet):
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0211j/DDI0211J_arm1136_r1p5_trm.pdf
Optimization guide for Intel XScale (used in Sharp Zaurus PDA):
http://download.intel.com/design/intelxscale/27347302.pdf
PowerPC-specific:
-----------------
PowerPC32/AltiVec PIM:
www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPEM.pdf
PowerPC32/AltiVec PEM:
www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf
CELL/SPU:
http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/30B3520C93F437AB87257060006FFE5E/$file/Language_Extensions_for_CBEA_2.4.pdf
http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F/$file/CBE_Handbook_v1.1_24APR2007_pub.pdf
SPARC-specific:
---------------
SPARC Joint Programming Specification (JPS1): Commonality
http://www.fujitsu.com/downloads/PRMPWR/JPS1-R1.0.4-Common-pub.pdf
UltraSPARC III Processor User's Manual (contains instruction timings)
http://www.sun.com/processors/manuals/USIIIv2.pdf
VIS Whitepaper (contains optimization guidelines)
http://www.sun.com/processors/vis/download/vis/vis_whitepaper.pdf
GCC asm links:
--------------
official doc but quite ugly
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
a bit old (note "+" is valid for input-output, even though the next disagrees)
http://www.cs.virginia.edu/~clc5q/gcc-inline-asm.pdf
|
