avcodec/tiff: Limit filtering to decoded data
[ffmpeg.git] / doc / optimization.txt
index 3a5d85e..974e2f9 100644 (file)
@@ -7,7 +7,7 @@ If you plan to do non-x86 architecture specific optimizations (SIMD normally),
 then take a look in the x86/ 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
+If you want to do x86 optimizations then you can either try to fine-tune the
 stuff in the x86 directory or find some other functions in the C source to
 optimize, but there aren't many left.
 
@@ -17,15 +17,15 @@ 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 recommended to look at older
-revisions of the interesting files (for a web frontend try ViewVC at
-http://svn.ffmpeg.org/ffmpeg/trunk/).
+revisions of the interesting files (web frontends for the various FFmpeg
+branches are listed at http://ffmpeg.org/download.html).
 Alternatively, look into the other architecture-specific versions in
 the x86/, 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)
+(http://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel)
 
 
 When is an optimization justified?
@@ -79,9 +79,6 @@ 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.
 
@@ -139,16 +136,13 @@ dct_unquantize_mpeg2
 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);
+    void (*put_pixels_clamped)(const int16_t *block/*align 16*/, uint8_t *pixels/*align 8*/, ptrdiff_t stride);
 
 
 General Tips:
@@ -167,11 +161,17 @@ do{
 For x86, mark registers that are clobbered in your asm. This means both
 general x86 registers (e.g. eax) as well as XMM registers. This last one is
 particularly important on Win64, where xmm6-15 are callee-save, and not
-restoring their contents leads to undefined results. In external asm (e.g.
-yasm), you do this by using:
-cglobal functon_name, num_args, num_regs, num_xmm_regs
+restoring their contents leads to undefined results. In external asm,
+you do this by using:
+cglobal function_name, num_args, num_regs, num_xmm_regs
 In inline asm, you specify clobbered registers at the end of your asm:
 __asm__(".." ::: "%eax").
+If gcc is not set to support sse (-msse) it will not accept xmm registers
+in the clobber list. For that we use two macros to declare the clobbers.
+XMM_CLOBBERS should be used when there are other clobbers, for example:
+__asm__(".." ::: XMM_CLOBBERS("xmm0",) "eax");
+and XMM_CLOBBERS_ONLY should be used when the only clobbers are xmm registers:
+__asm__(".." :: XMM_CLOBBERS_ONLY("xmm0"));
 
 Do not expect a compiler to maintain values in your registers between separate
 (inline) asm code blocks. It is not required to. For example, this is bad:
@@ -191,15 +191,20 @@ __asm__() block.
 Use external asm (nasm/yasm) or inline asm (__asm__()), do not use intrinsics.
 The latter requires a good optimizing compiler which gcc is not.
 
+When debugging a x86 external asm compilation issue, if lost in the macro
+expansions, add DBG=1 to your make command-line: the input file will be
+preprocessed, stripped of the debug/empty lines, then compiled, showing the
+actual lines causing issues.
+
 Inline asm vs. external asm
 ---------------------------
 Both inline asm (__asm__("..") in a .c file, handled by a compiler such as gcc)
-and external asm (.s or .asm files, handled by an assembler such as yasm/nasm)
+and external asm (.s or .asm files, handled by an assembler such as nasm/yasm)
 are accepted in FFmpeg. Which one to use differs per specific case.
 
 - if your code is intended to be inlined in a C function, inline asm is always
    better, because external asm cannot be inlined
-- if your code calls external functions, yasm is always better
+- if your code calls external functions, external asm is always better
 - if your code takes huge and complex structs as function arguments (e.g.
    MpegEncContext; note that this is not ideal and is discouraged if there
    are alternatives), then inline asm is always better, because predicting
@@ -247,7 +252,7 @@ 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
-Intel Wireless MMX2 Coprocessor: Programmers Reference Manual
+Intel Wireless MMX 2 Coprocessor: Programmers Reference Manual
 http://download.intel.com/design/intelxscale/31451001.pdf
 
 PowerPC-specific:
@@ -262,17 +267,6 @@ 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