| 1 | optimization Tips (for libavcodec): |
| 2 | =================================== |
| 3 | |
| 4 | What to optimize: |
| 5 | ----------------- |
| 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. |
| 9 | |
| 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. |
| 13 | |
| 14 | |
| 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. |
| 26 | |
| 27 | NOTE: If you still don't understand some function, ask at our mailing list!!! |
| 28 | (http://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel) |
| 29 | |
| 30 | |
| 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. |
| 42 | |
| 43 | |
| 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. |
| 48 | |
| 49 | put(_no_rnd)_pixels{,_x2,_y2,_xy2} |
| 50 | Used in motion compensation (en/decoding). |
| 51 | |
| 52 | avg_pixels{,_x2,_y2,_xy2} |
| 53 | Used in motion compensation of B-frames. |
| 54 | These are less important than the put*pixels functions. |
| 55 | |
| 56 | avg_no_rnd_pixels* |
| 57 | unused |
| 58 | |
| 59 | pix_abs16x16{,_x2,_y2,_xy2} |
| 60 | Used in motion estimation (encoding) with SAD. |
| 61 | |
| 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. |
| 65 | |
| 66 | put_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 | |
| 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 |
| 76 | encoding & decoding. |
| 77 | |
| 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. |
| 80 | Don't optimize them. |
| 81 | |
| 82 | add_bytes/diff_bytes |
| 83 | For huffyuv only, optimize if you want a faster ffhuffyuv codec. |
| 84 | |
| 85 | get_pixels / diff_pixels |
| 86 | Used for encoding, easy. |
| 87 | |
| 88 | clear_blocks |
| 89 | easiest to optimize |
| 90 | |
| 91 | gmc |
| 92 | Used for MPEG-4 gmc. |
| 93 | Optimizing this should have a significant effect on the gmc decoding |
| 94 | speed. |
| 95 | |
| 96 | gmc1 |
| 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 | |
| 104 | pix_sum |
| 105 | Used for encoding. |
| 106 | |
| 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 |
| 111 | really useful. |
| 112 | |
| 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. |
| 117 | |
| 118 | idct/fdct |
| 119 | idct (encoding & decoding) |
| 120 | fdct (encoding) |
| 121 | difficult to optimize |
| 122 | |
| 123 | dct_quantize_trellis |
| 124 | Used for encoding with trellis quantization. |
| 125 | difficult to optimize |
| 126 | |
| 127 | dct_quantize |
| 128 | Used for encoding. |
| 129 | |
| 130 | dct_unquantize_mpeg1 |
| 131 | Used in MPEG-1 en/decoding. |
| 132 | |
| 133 | dct_unquantize_mpeg2 |
| 134 | Used in MPEG-2 en/decoding. |
| 135 | |
| 136 | dct_unquantize_h263 |
| 137 | Used in MPEG-4/H.263 en/decoding. |
| 138 | |
| 139 | |
| 140 | |
| 141 | Alignment: |
| 142 | Some instructions on some architectures have strict alignment restrictions, |
| 143 | for example most SSE/SSE2 instructions on x86. |
| 144 | The minimum guaranteed alignment is written in the .h files, for example: |
| 145 | void (*put_pixels_clamped)(const int16_t *block/*align 16*/, UINT8 *pixels/*align 8*/, int line_size); |
| 146 | |
| 147 | |
| 148 | General Tips: |
| 149 | ------------- |
| 150 | Use asm loops like: |
| 151 | __asm__( |
| 152 | "1: .... |
| 153 | ... |
| 154 | "jump_instruction .... |
| 155 | Do not use C loops: |
| 156 | do{ |
| 157 | __asm__( |
| 158 | ... |
| 159 | }while() |
| 160 | |
| 161 | For x86, mark registers that are clobbered in your asm. This means both |
| 162 | general x86 registers (e.g. eax) as well as XMM registers. This last one is |
| 163 | particularly important on Win64, where xmm6-15 are callee-save, and not |
| 164 | restoring their contents leads to undefined results. In external asm (e.g. |
| 165 | yasm), you do this by using: |
| 166 | cglobal functon_name, num_args, num_regs, num_xmm_regs |
| 167 | In inline asm, you specify clobbered registers at the end of your asm: |
| 168 | __asm__(".." ::: "%eax"). |
| 169 | If gcc is not set to support sse (-msse) it will not accept xmm registers |
| 170 | in the clobber list. For that we use two macros to declare the clobbers. |
| 171 | XMM_CLOBBERS should be used when there are other clobbers, for example: |
| 172 | __asm__(".." ::: XMM_CLOBBERS("xmm0",) "eax"); |
| 173 | and XMM_CLOBBERS_ONLY should be used when the only clobbers are xmm registers: |
| 174 | __asm__(".." :: XMM_CLOBBERS_ONLY("xmm0")); |
| 175 | |
| 176 | Do 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 |
| 187 | Code that depends on data in registries being untouched, should be written as |
| 188 | a single __asm__() statement. Ideally, a single function contains only one |
| 189 | __asm__() block. |
| 190 | |
| 191 | Use external asm (nasm/yasm) or inline asm (__asm__()), do not use intrinsics. |
| 192 | The latter requires a good optimizing compiler which gcc is not. |
| 193 | |
| 194 | Inline asm vs. external asm |
| 195 | --------------------------- |
| 196 | Both inline asm (__asm__("..") in a .c file, handled by a compiler such as gcc) |
| 197 | and external asm (.s or .asm files, handled by an assembler such as yasm/nasm) |
| 198 | are accepted in FFmpeg. Which one to use differs per specific case. |
| 199 | |
| 200 | - if your code is intended to be inlined in a C function, inline asm is always |
| 201 | better, because external asm cannot be inlined |
| 202 | - if your code calls external functions, yasm is always better |
| 203 | - if your code takes huge and complex structs as function arguments (e.g. |
| 204 | MpegEncContext; note that this is not ideal and is discouraged if there |
| 205 | are alternatives), then inline asm is always better, because predicting |
| 206 | member offsets in complex structs is almost impossible. It's safest to let |
| 207 | the compiler take care of that |
| 208 | - in many cases, both can be used and it just depends on the preference of the |
| 209 | person writing the asm. For new asm, the choice is up to you. For existing |
| 210 | asm, you'll likely want to maintain whatever form it is currently in unless |
| 211 | there is a good reason to change it. |
| 212 | - if, for some reason, you believe that a particular chunk of existing external |
| 213 | asm could be improved upon further if written in inline asm (or the other |
| 214 | way around), then please make the move from external asm <-> inline asm a |
| 215 | separate patch before your patches that actually improve the asm. |
| 216 | |
| 217 | |
| 218 | Links: |
| 219 | ====== |
| 220 | http://www.aggregate.org/MAGIC/ |
| 221 | |
| 222 | x86-specific: |
| 223 | ------------- |
| 224 | http://developer.intel.com/design/pentium4/manuals/248966.htm |
| 225 | |
| 226 | The IA-32 Intel Architecture Software Developer's Manual, Volume 2: |
| 227 | Instruction Set Reference |
| 228 | http://developer.intel.com/design/pentium4/manuals/245471.htm |
| 229 | |
| 230 | http://www.agner.org/assem/ |
| 231 | |
| 232 | AMD Athlon Processor x86 Code Optimization Guide: |
| 233 | http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf |
| 234 | |
| 235 | |
| 236 | ARM-specific: |
| 237 | ------------- |
| 238 | ARM Architecture Reference Manual (up to ARMv5TE): |
| 239 | http://www.arm.com/community/university/eulaarmarm.html |
| 240 | |
| 241 | Procedure Call Standard for the ARM Architecture: |
| 242 | http://www.arm.com/pdfs/aapcs.pdf |
| 243 | |
| 244 | Optimization guide for ARM9E (used in Nokia 770 Internet Tablet): |
| 245 | http://infocenter.arm.com/help/topic/com.arm.doc.ddi0240b/DDI0240A.pdf |
| 246 | Optimization guide for ARM11 (used in Nokia N800 Internet Tablet): |
| 247 | http://infocenter.arm.com/help/topic/com.arm.doc.ddi0211j/DDI0211J_arm1136_r1p5_trm.pdf |
| 248 | Optimization guide for Intel XScale (used in Sharp Zaurus PDA): |
| 249 | http://download.intel.com/design/intelxscale/27347302.pdf |
| 250 | Intel Wireless MMX 2 Coprocessor: Programmers Reference Manual |
| 251 | http://download.intel.com/design/intelxscale/31451001.pdf |
| 252 | |
| 253 | PowerPC-specific: |
| 254 | ----------------- |
| 255 | PowerPC32/AltiVec PIM: |
| 256 | www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPEM.pdf |
| 257 | |
| 258 | PowerPC32/AltiVec PEM: |
| 259 | www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf |
| 260 | |
| 261 | CELL/SPU: |
| 262 | http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/30B3520C93F437AB87257060006FFE5E/$file/Language_Extensions_for_CBEA_2.4.pdf |
| 263 | http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F/$file/CBE_Handbook_v1.1_24APR2007_pub.pdf |
| 264 | |
| 265 | GCC asm links: |
| 266 | -------------- |
| 267 | official doc but quite ugly |
| 268 | http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html |
| 269 | |
| 270 | a bit old (note "+" is valid for input-output, even though the next disagrees) |
| 271 | http://www.cs.virginia.edu/~clc5q/gcc-inline-asm.pdf |