[FFmpeg-devel] [PATCH 0/2] x86: hevc_mc: use proxy functions
James Almer
jamrial at gmail.com
Fri Oct 3 19:36:23 CEST 2014
On 02/10/14 3:52 PM, Christophe Gisquet wrote:
> Preamble: I don't see an easy way out of the issue, and this patchset
> has several drawbacks, so I don't mind if it is not applied.
>
> The dsp init instanciates most widths and thus unrolls the calls. As a
> consequence, the object size balloons quite quickly:
> x86/hevc_mc.o: 115920
> x86/hevcdsp_init.o: 185404
>
> This to be compared to vp9 (albeit it probably has fewer special cases):
> x86/vp9mc.o: 11408
> x86/vp9dsp_init.o: 25260
>
> To reduce this, use instead "proxy" functions that will loop on calling
> a specific function to achieve the intended width. The current code is
> somewhat dirty (copypasta) and will probably make it difficult to add
> new instruction sets. But doing this while keeping the current code
> will causes an even larger increase (as experienced by having SSSE3 and
> SSE4 versions), which doesn't sound acceptable to me.
>
> Beside the code size reduction, it is possible (although probably
> difficult to measure) that that amount of code causes important
> cache pressure.
>
> Overall, this is more of a hackish patch. The issue looks wider to me,
> and probably requires a serious amount of work.
When i first tried to tackle the libswresample asm to reduce the overall
object size, the general reaction was that speed is more important than
size.
Adding AVX2 MC functions is probably more attractive to users than having
the library be a hundred or so kbs smaller.
I'm all for smaller and cleaner source and object files, but if it makes
it hard to add new instruction sets and at the same time brings a small
performance hit, then I'm not sure it's worth it.
Just my two cents. It's up to HEVC maintainers to decide that anyway.
More information about the ffmpeg-devel
mailing list