1optimization Tips (for libavcodec): 2=================================== 3 4What to optimize: 5----------------- 6If you plan to do non-x86 architecture specific optimizations (SIMD normally), 7then take a look in the x86/ directory, as most important functions are 8already optimized for MMX. 9 10If you want to do x86 optimizations then you can either try to fine-tune the 11stuff in the x86 directory or find some other functions in the C source to 12optimize, but there aren't many left. 13 14 15Understanding these overoptimized functions: 16-------------------------------------------- 17As many functions tend to be a bit difficult to understand because 18of optimizations, it can be hard to optimize them further, or write 19architecture-specific versions. It is recommended to look at older 20revisions of the interesting files (web frontends for the various FFmpeg 21branches are listed at http://ffmpeg.org/download.html). 22Alternatively, look into the other architecture-specific versions in 23the x86/, ppc/, alpha/ subdirectories. Even if you don't exactly 24comprehend the instructions, it could help understanding the functions 25and how they can be optimized. 26 27NOTE: If you still don't understand some function, ask at our mailing list!!! 28(http://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel) 29 30 31When is an optimization justified? 32---------------------------------- 33Normally, clean and simple optimizations for widely used codecs are 34justified even if they only achieve an overall speedup of 0.1%. These 35speedups accumulate and can make a big difference after awhile. Also, if 36none of the following factors get worse due to an optimization -- speed, 37binary code size, source size, source readability -- and at least one 38factor improves, then an optimization is always a good idea even if the 39overall gain is less than 0.1%. For obscure codecs that are not often 40used, the goal is more toward keeping the code clean, small, and 41readable instead of making it 1% faster. 42 43 44WTF is that function good for ....: 45----------------------------------- 46The primary purpose of this list is to avoid wasting time optimizing functions 47which are rarely used. 48 49put(_no_rnd)_pixels{,_x2,_y2,_xy2} 50 Used in motion compensation (en/decoding). 51 52avg_pixels{,_x2,_y2,_xy2} 53 Used in motion compensation of B-frames. 54 These are less important than the put*pixels functions. 55 56avg_no_rnd_pixels* 57 unused 58 59pix_abs16x16{,_x2,_y2,_xy2} 60 Used in motion estimation (encoding) with SAD. 61 62pix_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. 65 66put_mspel8_mc* / wmv2_mspel8* 67 Used only in WMV2. 68 it is not recommended that you waste your time with these, as WMV2 69 is an ugly and relatively useless codec. 70 71mpeg4_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 76 encoding & decoding. 77 78qpel{8,16}_mc??_old_c / *pixels{8,16}_l4 79 Just used to work around a bug in an old libavcodec encoder version. 80 Don't optimize them. 81 82add_bytes/diff_bytes 83 For huffyuv only, optimize if you want a faster ffhuffyuv codec. 84 85get_pixels / diff_pixels 86 Used for encoding, easy. 87 88clear_blocks 89 easiest to optimize 90 91gmc 92 Used for MPEG-4 gmc. 93 Optimizing this should have a significant effect on the gmc decoding 94 speed. 95 96gmc1 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 101 just 1 warp point). 102 Note: DivX5 gmc always uses just 1 warp point. 103 104pix_sum 105 Used for encoding. 106 107hadamard8_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 111 really useful. 112 113put_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. 117 118idct/fdct 119 idct (encoding & decoding) 120 fdct (encoding) 121 difficult to optimize 122 123dct_quantize_trellis 124 Used for encoding with trellis quantization. 125 difficult to optimize 126 127dct_quantize 128 Used for encoding. 129 130dct_unquantize_mpeg1 131 Used in MPEG-1 en/decoding. 132 133dct_unquantize_mpeg2 134 Used in MPEG-2 en/decoding. 135 136dct_unquantize_h263 137 Used in MPEG-4/H.263 en/decoding. 138 139 140 141Alignment: 142Some instructions on some architectures have strict alignment restrictions, 143for example most SSE/SSE2 instructions on x86. 144The minimum guaranteed alignment is written in the .h files, for example: 145 void (*put_pixels_clamped)(const int16_t *block/*align 16*/, uint8_t *pixels/*align 8*/, ptrdiff_t stride); 146 147 148General Tips: 149------------- 150Use asm loops like: 151__asm__( 152 "1: .... 153 ... 154 "jump_instruction .... 155Do not use C loops: 156do{ 157 __asm__( 158 ... 159}while() 160 161For x86, mark registers that are clobbered in your asm. This means both 162general x86 registers (e.g. eax) as well as XMM registers. This last one is 163particularly important on Win64, where xmm6-15 are callee-save, and not 164restoring their contents leads to undefined results. In external asm, 165you do this by using: 166cglobal function_name, num_args, num_regs, num_xmm_regs 167In inline asm, you specify clobbered registers at the end of your asm: 168__asm__(".." ::: "%eax"). 169If gcc is not set to support sse (-msse) it will not accept xmm registers 170in the clobber list. For that we use two macros to declare the clobbers. 171XMM_CLOBBERS should be used when there are other clobbers, for example: 172__asm__(".." ::: XMM_CLOBBERS("xmm0",) "eax"); 173and XMM_CLOBBERS_ONLY should be used when the only clobbers are xmm registers: 174__asm__(".." :: XMM_CLOBBERS_ONLY("xmm0")); 175 176Do not expect a compiler to maintain values in your registers between separate 177(inline) asm code blocks. It is not required to. For example, this is bad: 178__asm__("movdqa %0, %%xmm7" : src); 179/* do something */ 180__asm__("movdqa %%xmm7, %1" : dst); 181- first of all, you're assuming that the compiler will not use xmm7 in 182 between the two asm blocks. It probably won't when you test it, but it's 183 a poor assumption that will break at some point for some --cpu compiler flag 184- secondly, you didn't mark xmm7 as clobbered. If you did, the compiler would 185 have restored the original value of xmm7 after the first asm block, thus 186 rendering the combination of the two blocks of code invalid 187Code that depends on data in registries being untouched, should be written as 188a single __asm__() statement. Ideally, a single function contains only one 189__asm__() block. 190 191Use external asm (nasm/yasm) or inline asm (__asm__()), do not use intrinsics. 192The latter requires a good optimizing compiler which gcc is not. 193 194When debugging a x86 external asm compilation issue, if lost in the macro 195expansions, add DBG=1 to your make command-line: the input file will be 196preprocessed, stripped of the debug/empty lines, then compiled, showing the 197actual lines causing issues. 198 199Inline asm vs. external asm 200--------------------------- 201Both inline asm (__asm__("..") in a .c file, handled by a compiler such as gcc) 202and external asm (.s or .asm files, handled by an assembler such as nasm/yasm) 203are accepted in FFmpeg. Which one to use differs per specific case. 204 205- if your code is intended to be inlined in a C function, inline asm is always 206 better, because external asm cannot be inlined 207- if your code calls external functions, external asm is always better 208- if your code takes huge and complex structs as function arguments (e.g. 209 MpegEncContext; note that this is not ideal and is discouraged if there 210 are alternatives), then inline asm is always better, because predicting 211 member offsets in complex structs is almost impossible. It's safest to let 212 the compiler take care of that 213- in many cases, both can be used and it just depends on the preference of the 214 person writing the asm. For new asm, the choice is up to you. For existing 215 asm, you'll likely want to maintain whatever form it is currently in unless 216 there is a good reason to change it. 217- if, for some reason, you believe that a particular chunk of existing external 218 asm could be improved upon further if written in inline asm (or the other 219 way around), then please make the move from external asm <-> inline asm a 220 separate patch before your patches that actually improve the asm. 221 222 223Links: 224====== 225http://www.aggregate.org/MAGIC/ 226 227x86-specific: 228------------- 229http://developer.intel.com/design/pentium4/manuals/248966.htm 230 231The IA-32 Intel Architecture Software Developer's Manual, Volume 2: 232Instruction Set Reference 233http://developer.intel.com/design/pentium4/manuals/245471.htm 234 235http://www.agner.org/assem/ 236 237AMD Athlon Processor x86 Code Optimization Guide: 238http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf 239 240 241ARM-specific: 242------------- 243ARM Architecture Reference Manual (up to ARMv5TE): 244http://www.arm.com/community/university/eulaarmarm.html 245 246Procedure Call Standard for the ARM Architecture: 247http://www.arm.com/pdfs/aapcs.pdf 248 249Optimization guide for ARM9E (used in Nokia 770 Internet Tablet): 250http://infocenter.arm.com/help/topic/com.arm.doc.ddi0240b/DDI0240A.pdf 251Optimization guide for ARM11 (used in Nokia N800 Internet Tablet): 252http://infocenter.arm.com/help/topic/com.arm.doc.ddi0211j/DDI0211J_arm1136_r1p5_trm.pdf 253Optimization guide for Intel XScale (used in Sharp Zaurus PDA): 254http://download.intel.com/design/intelxscale/27347302.pdf 255Intel Wireless MMX 2 Coprocessor: Programmers Reference Manual 256http://download.intel.com/design/intelxscale/31451001.pdf 257 258PowerPC-specific: 259----------------- 260PowerPC32/AltiVec PIM: 261www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPEM.pdf 262 263PowerPC32/AltiVec PEM: 264www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf 265 266CELL/SPU: 267http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/30B3520C93F437AB87257060006FFE5E/$file/Language_Extensions_for_CBEA_2.4.pdf 268http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F/$file/CBE_Handbook_v1.1_24APR2007_pub.pdf 269 270GCC asm links: 271-------------- 272official doc but quite ugly 273http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html 274 275a bit old (note "+" is valid for input-output, even though the next disagrees) 276http://www.cs.virginia.edu/~clc5q/gcc-inline-asm.pdf 277