aboutsummaryrefslogtreecommitdiffstats
path: root/doc/optimization.txt
blob: 08caa89c1b80effa16a5159a4573786bfeac76b9 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
optimization Tips (for libavcodec):

What to optimize:
if you plan to do non-x86 architecture specific optimiztions (SIMD normally) then
take a look in the i386/ directory, as most important functions are allready
optimized for MMX

if you want to do x86 optimizations then u can either try to finetune the stuff in the
i386 directory or find some other functions in the c source to optimize, but there
arent many left

Understanding these overoptimized functions:
as many functions, like the c ones tend to be a bit unreadable currently becouse 
of optimizations it is difficult to understand them (and write arichtecture 
specific versions, or optimize the c functions further) it is recommanded to look
at older CVS versions of the interresting files (just use CVSWEB at 
http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/?cvsroot=FFmpeg)
or perhaps look into the other architecture specific versions in i386/, ppc/, 
alpha/, ...; even if u dont understand the instructions exactly it could help
understanding the functions & how they can be optimized

NOTE:!!! if u still dont understand some function then ask at our mailing list!!!
(http://www1.mplayerhq.hu/mailman/listinfo/ffmpeg-devel)



wtf is that function good for ....:
the primary purpose of that list is to avoid wasting time to optimize functions
which are rarely used

put(_no_rnd)_pixels{,_x2,_y2,_xy2}
	used in motion compensation (en/decoding)

avg_pixels{,_x2,_y2,_xy2}
	used in motion compensation of B Frames 
	these are less important then the put*pixels functions

avg_no_rnd_pixels*
	unused

pix_abs16x16{,_x2,_y2,_xy2}
	used in motion estimation (encoding) with SAD

pix_abs8x8{,_x2,_y2,_xy2}
	used in motion estimation (encoding) with SAD of MPEG4 4MV only
	these are less important then the pix_abs16x16* functions

put_mspel8_mc* / wmv2_mspel8*
	used only in WMV2
	it is not recommanded that u waste ur time with these, as WMV2 is a
	ugly and relativly useless codec

mpeg4_qpel* / *qpel_mc*
	use in MPEG4 qpel Motion compensation (encoding & decoding)
	the qpel8 functions are used only for 4mv
	the avg_* functions are used only for b frames
	optimizing them should have a significant impact on qpel encoding & decoding
 
qpel{8,16}_mc??_old_c / *pixels{8,16}_l4
	just used to workaround a bug in old libavcodec encoder
        dont optimze them

tpel_mc_func {put,avg}_tpel_pixels_tab
	used only for SVQ3, so only optimze them if u need fast SVQ3 decoding

add_bytes/diff_bytes
	for huffyuv only, optimize if u want a faster ff-huffyuv codec

get_pixels / diff_pixels
	used for encoding, easy
        
clear_blocks
	easiest, to optimize
        
gmc
	used for mpeg4 gmc
        optimizing this should have a significant effect on the gmc decoding speed but
        its very likely impossible to write in SIMD

gmc1
	used for chroma blocks in mpeg4 gmc with 1 warp point
	(there are 4 luma & 2 chroma blocks per macrobock, so 
        only 1/3 of the gmc blocks use this, the other 2/3 
        use the normal put_pixel* code, but only if there is 
        just 1 warp point)
        Note: Divx5 gmc always uses just 1 warp point

pix_sum
	used for encoding
        
hadamard8_diff / sse / sad == pix_norm1 / dct_sad / quant_psnr / rd / bit
	specific compare functions used in encoding, it depends upon the command line
        switches which of these are used
        dont waste ur time with dct_sad & quant_psnr they arent really usefull

put_pixels_clamped / add_pixels_clamped
	used for en/decoding in the IDCT, easy
        Note, some optimized IDCTs have the add/put clamped code included and then 
        put_pixels_clamped / add_pixels_clamped will be unused

idct/fdct
	idct (encoding & decoding)
        fdct (encoding)
	difficult to optimize
        
dct_quantize_trellis
	used for encoding with trellis quantization
	difficult to optimize 

dct_quantize
	used for encoding
        
dct_unquantize_mpeg1
	used in mpeg1 en/decoding

dct_unquantize_mpeg2
	used in mpeg2 en/decoding

dct_unquantize_h263
	used in mpeg4/h263 en/decoding

FIXME remaining functions?
btw, most of these 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 inctructios on X86
the minimum guranteed alignment is writen in the .h files
for example: 
    void (*put_pixels_clamped)(const DCTELEM *block/*align 16*/, UINT8 *pixels/*align 8*/, int line_size);



Links:
http://www.aggregate.org/MAGIC/

X86 specific:
http://developer.intel.com/design/pentium4/manuals/248966.htm

The IA-32 Intel Architecture Software Developer's Manual, Volume 2: 
Instruction Set Reference
http://developer.intel.com/design/pentium4/manuals/245471.htm

http://www.agner.org/assem/

AMD Athlon Processor x86 Code Optimization Guide:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf

GCC asm links:
official doc but quite ugly
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

a bit old (note "+" is valid for input-output, even though the next says its not)
http://www.cs.virginia.edu/~clc5q/gcc-inline-asm.pdf