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

2014-10-04 Thread Christophe Gisquet
Hi, 2014-10-04 1:19 GMT+02:00 James Almer : > Or how everything is declared as sse4 even though less than half the code > actually uses sse4 instructions. The incorrect insn patch actually caught another issue in qpel_hv (where packusdw is required) , which made me the macros mess even more messi

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

2014-10-03 Thread James Almer
On 03/10/14 6:47 PM, Christophe Gisquet wrote: > Hi, > > 2014-10-03 19:36 GMT+02:00 James Almer : >> 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 the

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

2014-10-03 Thread Christophe Gisquet
Hi, 2014-10-03 19:36 GMT+02:00 James Almer : > 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%) > Adding AVX2 MC functio

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

2014-10-03 Thread James Almer
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 q

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

2014-10-02 Thread Christophe Gisquet
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