1 optimization Tips (for libavcodec):
2 ===================================
6 If you plan to do non-x86 architecture specific optimizations (SIMD normally),
7 then take a look in the x86/ directory, as most important functions are
8 already optimized for MMX.
10 If you want to do x86 optimizations then you can either try to finetune the
11 stuff in the x86 directory or find some other functions in the C source to
12 optimize, but there aren't many left.
15 Understanding these overoptimized functions:
16 --------------------------------------------
17 As many functions tend to be a bit difficult to understand because
18 of optimizations, it can be hard to optimize them further, or write
19 architecture-specific versions. It is recommended to look at older
20 revisions of the interesting files (web frontends for the various FFmpeg
21 branches are listed at http://ffmpeg.org/download.html).
22 Alternatively, look into the other architecture-specific versions in
23 the x86/, ppc/, alpha/ subdirectories. Even if you don't exactly
24 comprehend the instructions, it could help understanding the functions
25 and how they can be optimized.
27 NOTE: If you still don't understand some function, ask at our mailing list!!!
28 (http://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel)
31 When is an optimization justified?
32 ----------------------------------
33 Normally, clean and simple optimizations for widely used codecs are
34 justified even if they only achieve an overall speedup of 0.1%. These
35 speedups accumulate and can make a big difference after awhile. Also, if
36 none of the following factors get worse due to an optimization -- speed,
37 binary code size, source size, source readability -- and at least one
38 factor improves, then an optimization is always a good idea even if the
39 overall gain is less than 0.1%. For obscure codecs that are not often
40 used, the goal is more toward keeping the code clean, small, and
41 readable instead of making it 1% faster.
44 WTF is that function good for ....:
45 -----------------------------------
46 The primary purpose of this list is to avoid wasting time optimizing functions
47 which are rarely used.
49 put(_no_rnd)_pixels{,_x2,_y2,_xy2}
50 Used in motion compensation (en/decoding).
52 avg_pixels{,_x2,_y2,_xy2}
53 Used in motion compensation of B-frames.
54 These are less important than the put*pixels functions.
59 pix_abs16x16{,_x2,_y2,_xy2}
60 Used in motion estimation (encoding) with SAD.
62 pix_abs8x8{,_x2,_y2,_xy2}
63 Used in motion estimation (encoding) with SAD of MPEG-4 4MV only.
64 These are less important than the pix_abs16x16* functions.
66 put_mspel8_mc* / wmv2_mspel8*
68 it is not recommended that you waste your time with these, as WMV2
69 is an ugly and relatively useless codec.
71 mpeg4_qpel* / *qpel_mc*
72 Used in MPEG-4 qpel motion compensation (encoding & decoding).
73 The qpel8 functions are used only for 4mv,
74 the avg_* functions are used only for B-frames.
75 Optimizing them should have a significant impact on qpel
78 qpel{8,16}_mc??_old_c / *pixels{8,16}_l4
79 Just used to work around a bug in an old libavcodec encoder version.
83 For huffyuv only, optimize if you want a faster ffhuffyuv codec.
85 get_pixels / diff_pixels
86 Used for encoding, easy.
93 Optimizing this should have a significant effect on the gmc decoding
97 Used for chroma blocks in MPEG-4 gmc with 1 warp point
98 (there are 4 luma & 2 chroma blocks per macroblock, so
99 only 1/3 of the gmc blocks use this, the other 2/3
100 use the normal put_pixel* code, but only if there is
102 Note: DivX5 gmc always uses just 1 warp point.
107 hadamard8_diff / sse / sad == pix_norm1 / dct_sad / quant_psnr / rd / bit
108 Specific compare functions used in encoding, it depends upon the
109 command line switches which of these are used.
110 Don't waste your time with dct_sad & quant_psnr, they aren't
113 put_pixels_clamped / add_pixels_clamped
114 Used for en/decoding in the IDCT, easy.
115 Note, some optimized IDCTs have the add/put clamped code included and
116 then put_pixels_clamped / add_pixels_clamped will be unused.
119 idct (encoding & decoding)
121 difficult to optimize
124 Used for encoding with trellis quantization.
125 difficult to optimize
131 Used in MPEG-1 en/decoding.
134 Used in MPEG-2 en/decoding.
137 Used in MPEG-4/H.263 en/decoding.
139 FIXME remaining functions?
140 BTW, most of these functions are in dsputil.c/.h, some are in mpegvideo.c/.h.
145 Some instructions on some architectures have strict alignment restrictions,
146 for example most SSE/SSE2 instructions on x86.
147 The minimum guaranteed alignment is written in the .h files, for example:
148 void (*put_pixels_clamped)(const int16_t *block/*align 16*/, UINT8 *pixels/*align 8*/, int line_size);
157 "jump_instruction ....
164 For x86, mark registers that are clobbered in your asm. This means both
165 general x86 registers (e.g. eax) as well as XMM registers. This last one is
166 particularly important on Win64, where xmm6-15 are callee-save, and not
167 restoring their contents leads to undefined results. In external asm (e.g.
168 yasm), you do this by using:
169 cglobal functon_name, num_args, num_regs, num_xmm_regs
170 In inline asm, you specify clobbered registers at the end of your asm:
171 __asm__(".." ::: "%eax").
172 If gcc is not set to support sse (-msse) it will not accept xmm registers
173 in the clobber list. For that we use two macros to declare the clobbers.
174 XMM_CLOBBERS should be used when there are other clobbers, for example:
175 __asm__(".." ::: XMM_CLOBBERS("xmm0",) "eax");
176 and XMM_CLOBBERS_ONLY should be used when the only clobbers are xmm registers:
177 __asm__(".." :: XMM_CLOBBERS_ONLY("xmm0"));
179 Do not expect a compiler to maintain values in your registers between separate
180 (inline) asm code blocks. It is not required to. For example, this is bad:
181 __asm__("movdqa %0, %%xmm7" : src);
183 __asm__("movdqa %%xmm7, %1" : dst);
184 - first of all, you're assuming that the compiler will not use xmm7 in
185 between the two asm blocks. It probably won't when you test it, but it's
186 a poor assumption that will break at some point for some --cpu compiler flag
187 - secondly, you didn't mark xmm7 as clobbered. If you did, the compiler would
188 have restored the original value of xmm7 after the first asm block, thus
189 rendering the combination of the two blocks of code invalid
190 Code that depends on data in registries being untouched, should be written as
191 a single __asm__() statement. Ideally, a single function contains only one
194 Use external asm (nasm/yasm) or inline asm (__asm__()), do not use intrinsics.
195 The latter requires a good optimizing compiler which gcc is not.
197 Inline asm vs. external asm
198 ---------------------------
199 Both inline asm (__asm__("..") in a .c file, handled by a compiler such as gcc)
200 and external asm (.s or .asm files, handled by an assembler such as yasm/nasm)
201 are accepted in FFmpeg. Which one to use differs per specific case.
203 - if your code is intended to be inlined in a C function, inline asm is always
204 better, because external asm cannot be inlined
205 - if your code calls external functions, yasm is always better
206 - if your code takes huge and complex structs as function arguments (e.g.
207 MpegEncContext; note that this is not ideal and is discouraged if there
208 are alternatives), then inline asm is always better, because predicting
209 member offsets in complex structs is almost impossible. It's safest to let
210 the compiler take care of that
211 - in many cases, both can be used and it just depends on the preference of the
212 person writing the asm. For new asm, the choice is up to you. For existing
213 asm, you'll likely want to maintain whatever form it is currently in unless
214 there is a good reason to change it.
215 - if, for some reason, you believe that a particular chunk of existing external
216 asm could be improved upon further if written in inline asm (or the other
217 way around), then please make the move from external asm <-> inline asm a
218 separate patch before your patches that actually improve the asm.
223 http://www.aggregate.org/MAGIC/
227 http://developer.intel.com/design/pentium4/manuals/248966.htm
229 The IA-32 Intel Architecture Software Developer's Manual, Volume 2:
230 Instruction Set Reference
231 http://developer.intel.com/design/pentium4/manuals/245471.htm
233 http://www.agner.org/assem/
235 AMD Athlon Processor x86 Code Optimization Guide:
236 http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf
241 ARM Architecture Reference Manual (up to ARMv5TE):
242 http://www.arm.com/community/university/eulaarmarm.html
244 Procedure Call Standard for the ARM Architecture:
245 http://www.arm.com/pdfs/aapcs.pdf
247 Optimization guide for ARM9E (used in Nokia 770 Internet Tablet):
248 http://infocenter.arm.com/help/topic/com.arm.doc.ddi0240b/DDI0240A.pdf
249 Optimization guide for ARM11 (used in Nokia N800 Internet Tablet):
250 http://infocenter.arm.com/help/topic/com.arm.doc.ddi0211j/DDI0211J_arm1136_r1p5_trm.pdf
251 Optimization guide for Intel XScale (used in Sharp Zaurus PDA):
252 http://download.intel.com/design/intelxscale/27347302.pdf
253 Intel Wireless MMX 2 Coprocessor: Programmers Reference Manual
254 http://download.intel.com/design/intelxscale/31451001.pdf
258 PowerPC32/AltiVec PIM:
259 www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPEM.pdf
261 PowerPC32/AltiVec PEM:
262 www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf
265 http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/30B3520C93F437AB87257060006FFE5E/$file/Language_Extensions_for_CBEA_2.4.pdf
266 http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F/$file/CBE_Handbook_v1.1_24APR2007_pub.pdf
270 official doc but quite ugly
271 http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
273 a bit old (note "+" is valid for input-output, even though the next disagrees)
274 http://www.cs.virginia.edu/~clc5q/gcc-inline-asm.pdf