"Fossies" - the Fresh Open Source Software Archive

Member "ffmpeg-4.0.1/doc/optimization.txt" (20 Apr 2018, 10670 Bytes) of package /linux/misc/ffmpeg-4.0.1.tar.xz:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. See also the last Fossies "Diffs" side-by-side code changes report for "optimization.txt": 3.3.4_vs_3.4.

    1 optimization Tips (for libavcodec):
    2 ===================================
    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.
   10 If you want to do x86 optimizations then you can either try to fine-tune 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.
   56 avg_no_rnd_pixels*
   57     unused
   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*
   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.
   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.
   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.
   82 add_bytes/diff_bytes
   83     For huffyuv only, optimize if you want a faster ffhuffyuv codec.
   85 get_pixels / diff_pixels
   86     Used for encoding, easy.
   88 clear_blocks
   89     easiest to optimize
   91 gmc
   92     Used for MPEG-4 gmc.
   93     Optimizing this should have a significant effect on the gmc decoding
   94     speed.
   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.
  104 pix_sum
  105     Used for encoding.
  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.
  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.
  118 idct/fdct
  119     idct (encoding & decoding)
  120     fdct (encoding)
  121     difficult to optimize
  123 dct_quantize_trellis
  124     Used for encoding with trellis quantization.
  125     difficult to optimize
  127 dct_quantize
  128     Used for encoding.
  130 dct_unquantize_mpeg1
  131     Used in MPEG-1 en/decoding.
  133 dct_unquantize_mpeg2
  134     Used in MPEG-2 en/decoding.
  136 dct_unquantize_h263
  137     Used in MPEG-4/H.263 en/decoding.
  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_t *pixels/*align 8*/, ptrdiff_t stride);
  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()
  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,
  165 you do this by using:
  166 cglobal function_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"));
  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.
  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.
  194 When debugging a x86 external asm compilation issue, if lost in the macro
  195 expansions, add DBG=1 to your make command-line: the input file will be
  196 preprocessed, stripped of the debug/empty lines, then compiled, showing the
  197 actual lines causing issues.
  199 Inline asm vs. external asm
  200 ---------------------------
  201 Both inline asm (__asm__("..") in a .c file, handled by a compiler such as gcc)
  202 and external asm (.s or .asm files, handled by an assembler such as nasm/yasm)
  203 are accepted in FFmpeg. Which one to use differs per specific case.
  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.
  223 Links:
  224 ======
  225 http://www.aggregate.org/MAGIC/
  227 x86-specific:
  228 -------------
  229 http://developer.intel.com/design/pentium4/manuals/248966.htm
  231 The IA-32 Intel Architecture Software Developer's Manual, Volume 2:
  232 Instruction Set Reference
  233 http://developer.intel.com/design/pentium4/manuals/245471.htm
  235 http://www.agner.org/assem/
  237 AMD Athlon Processor x86 Code Optimization Guide:
  238 http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf
  241 ARM-specific:
  242 -------------
  243 ARM Architecture Reference Manual (up to ARMv5TE):
  244 http://www.arm.com/community/university/eulaarmarm.html
  246 Procedure Call Standard for the ARM Architecture:
  247 http://www.arm.com/pdfs/aapcs.pdf
  249 Optimization guide for ARM9E (used in Nokia 770 Internet Tablet):
  250 http://infocenter.arm.com/help/topic/com.arm.doc.ddi0240b/DDI0240A.pdf
  251 Optimization guide for ARM11 (used in Nokia N800 Internet Tablet):
  252 http://infocenter.arm.com/help/topic/com.arm.doc.ddi0211j/DDI0211J_arm1136_r1p5_trm.pdf
  253 Optimization guide for Intel XScale (used in Sharp Zaurus PDA):
  254 http://download.intel.com/design/intelxscale/27347302.pdf
  255 Intel Wireless MMX 2 Coprocessor: Programmers Reference Manual
  256 http://download.intel.com/design/intelxscale/31451001.pdf
  258 PowerPC-specific:
  259 -----------------
  260 PowerPC32/AltiVec PIM:
  261 www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPEM.pdf
  263 PowerPC32/AltiVec PEM:
  264 www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf
  266 CELL/SPU:
  267 http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/30B3520C93F437AB87257060006FFE5E/$file/Language_Extensions_for_CBEA_2.4.pdf
  268 http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F/$file/CBE_Handbook_v1.1_24APR2007_pub.pdf
  270 GCC asm links:
  271 --------------
  272 official doc but quite ugly
  273 http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
  275 a bit old (note "+" is valid for input-output, even though the next disagrees)
  276 http://www.cs.virginia.edu/~clc5q/gcc-inline-asm.pdf