Hi, 2015-02-04 21:14 GMT+01:00 James Almer <jamr...@gmail.com>: > On 04/02/15 9:39 AM, Christophe Gisquet wrote: >> Are the first number for each case from before you split out the >> restore part? Otherwise, that's gruesome. > > The benchmarks were done with every patch up to this one applied, so yes, > after the > split. The file i used to bench went from ~36fps to ~46fps after this patch. > The C version must be pretty inefficient (That CMP macro inside the loop > probably > creates lots of branches). Or maybe GCC was dumb.
At this point this whole function spends more time copying data than in the dsp! > Ah, good to know it's constant now. Although until we add x86_32 versions of > these > functions it doesn't really bring any real benefit. > I'll update the prototype and assembly anyway. It was a bit arbitrary, and expecting you would need that change. Anything lower would break avx2 reads. > For that matter, do .asm files have access to FF_INPUT_BUFFER_PADDING_SIZE? Unfortunately no, for instance, I added an equivalent MAX_PB_SIZE to hevc_mc.asm, but this later one is pretty strongly set in stone. > if at > some point we change its value (For example, once AVX512 code starts being > committed), then srcstride will be something else. > Probably not a problem since whenever that constant is updated in avcodec.h it > can also be updated in hevc_sao.asm, but it would be nice not having to bother > doing that. It would need to go through config.asm I bet, but agreed, this may break. Unfortunately nothing automagical yet, but that's probably not the only code fragile to this. -- Christophe _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
