[FFmpeg-devel] [PATCH 0/2] x86: hevc_mc: use proxy functions

[James Almer]

On 03/10/14 6:47 PM, Christophe Gisquet wrote:
> Hi,
> 
> 2014-10-03 19:36 GMT+02:00 James Almer <jamrial at gmail.com>:
>> 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.
> 
> Wasn't the trade-off much worse there? (the impact here is around 1%)

Yeah, it was, fair enough.

> 
>> Adding AVX2 MC functions is probably more attractive to users than having
>> the library be a hundred or so kbs smaller.
> 
> Most probably, albeit I wonder how much it actually helps for MC. On
> the other hand, who will be willing to try and fix things in that
> code? The more I look at it, the more difficult it looks (to me).

No idea how much it helps there. It's already implemented in OpenHEVC afaik, 
so they surely know.

> 
> Another example: the whimsical xmm reg usage declaration. Not a real
> word bug, though.

Or how everything is declared as sse4 even though less than half the code 
actually uses sse4 instructions.
You already tried to deal with this in "x86: hevc_mc: port to SSSE3 v2", but 
it got blocked by one of the patches that broke x86_32. Maybe it's worth 
looking at again.
Hell, quite a few are sse2, even, but the macros are kinda messy and it's 
much easier declaring everything as ssse3/sse4 than micromanaging stuff.

> 
>> 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.
> 
> Yes, that's the trade-off I was more concerned with.
> 
>> Just my two cents. It's up to HEVC maintainers to decide that anyway.
> 
> I don't think the patch is acceptable either, but probably some time
> in the future, this would better be addressed. I don't expect it to
> happen, though.
> 
> Overall, there are much more important asm bits missing (idct, sao) anyway.

Plepere was working on that. Both are written as intrinsics already in OpenHEVC, 
and he was porting them to yasm last i checked.