[PATCH] MMX2/SSSE3 VC1 loop filter
Hi, Overall 17% faster decode on my Penryn, including the first function to use SSE4 instructions in ffmpeg! (which shave an entire 2 clocks off of vc1_h_loop_filter8 for me) One thing I don't understand is why the PSIGNW_SRA_MMX macro is necessary for correct results. I know that psignw isn't equivalent to ((a ^ b) - b), but the only difference I'm aware of is when b is 0, psignw sets a to 0 as well. It's probably a stupidly simple case that I'm missing... 700 dezicycles in vc1_v_loop_filter4_mmx2, 1048506 runs, 70 skips. 639 dezicycles in vc1_v_loop_filter4_ssse3, 1048447 runs, 129 skips 977 dezicycles in vc1_h_loop_filter4_mmx2, 2097069 runs, 83 skips. 951 dezicycles in vc1_h_loop_filter4_ssse3, 2097040 runs, 112 skips 1116 dezicycles in vc1_v_loop_filter8_mmx2, 33552803 runs, 1629 skips 677 dezicycles in vc1_v_loop_filter8_ssse3, 33552817 runs, 1615 skips 1648 dezicycles in vc1_h_loop_filter8_mmx2, 33552806 runs, 1626 skips 1158 dezicycles in vc1_h_loop_filter8_ssse3, 33552878 runs, 1554 skips 1137 dezicycles in vc1_h_loop_filter8_sse4, 33553447 runs, 985 skips
On Wed, Apr 01, 2009 at 05:06:59AM -0400, David Conrad wrote:
Overall 17% faster decode on my Penryn, including the first function to use SSE4 instructions in ffmpeg! (which shave an entire 2 clocks off of vc1_h_loop_filter8 for me)
One thing I don't understand is why the PSIGNW_SRA_MMX macro is necessary for correct results. I know that psignw isn't equivalent to ((a ^ b) - b), but the only difference I'm aware of is when b is 0, psignw sets a to 0 as well. It's probably a stupidly simple case that I'm missing...
700 dezicycles in vc1_v_loop_filter4_mmx2, 1048506 runs, 70 skips. 639 dezicycles in vc1_v_loop_filter4_ssse3, 1048447 runs, 129 skips
977 dezicycles in vc1_h_loop_filter4_mmx2, 2097069 runs, 83 skips. 951 dezicycles in vc1_h_loop_filter4_ssse3, 2097040 runs, 112 skips
1116 dezicycles in vc1_v_loop_filter8_mmx2, 33552803 runs, 1629 skips 677 dezicycles in vc1_v_loop_filter8_ssse3, 33552817 runs, 1615 skips
1648 dezicycles in vc1_h_loop_filter8_mmx2, 33552806 runs, 1626 skips 1158 dezicycles in vc1_h_loop_filter8_ssse3, 33552878 runs, 1554 skips 1137 dezicycles in vc1_h_loop_filter8_sse4, 33553447 runs, 985 skips
It seems this got lost?
On Sun, Jul 04, 2010 at 12:54:15PM +0200, Reimar D?ffinger wrote:
On Wed, Apr 01, 2009 at 05:06:59AM -0400, David Conrad wrote:
Overall 17% faster decode on my Penryn, including the first function to use SSE4 instructions in ffmpeg! (which shave an entire 2 clocks off of vc1_h_loop_filter8 for me)
One thing I don't understand is why the PSIGNW_SRA_MMX macro is necessary for correct results. I know that psignw isn't equivalent to ((a ^ b) - b), but the only difference I'm aware of is when b is 0, psignw sets a to 0 as well. It's probably a stupidly simple case that I'm missing...
700 dezicycles in vc1_v_loop_filter4_mmx2, 1048506 runs, 70 skips. 639 dezicycles in vc1_v_loop_filter4_ssse3, 1048447 runs, 129 skips
977 dezicycles in vc1_h_loop_filter4_mmx2, 2097069 runs, 83 skips. 951 dezicycles in vc1_h_loop_filter4_ssse3, 2097040 runs, 112 skips
1116 dezicycles in vc1_v_loop_filter8_mmx2, 33552803 runs, 1629 skips 677 dezicycles in vc1_v_loop_filter8_ssse3, 33552817 runs, 1615 skips
1648 dezicycles in vc1_h_loop_filter8_mmx2, 33552806 runs, 1626 skips 1158 dezicycles in vc1_h_loop_filter8_ssse3, 33552878 runs, 1554 skips 1137 dezicycles in vc1_h_loop_filter8_sse4, 33553447 runs, 985 skips
It seems this got lost?
probably it just slipped past me - I was visiting my homeland then If it still works then ok.
Kostya <kostya.shishkov <at> gmail.com> writes:
It seems this got lost?
probably it just slipped past me - I was visiting my homeland then
If it still works then ok.
I'd like to add two comments: Is there any indication that the C-version of the loop-filter is bit-exact? Am I correct that if not, this patch would not improve things? And since I consider this a more important codec than VP8: Could this be truly reviewed to see possible additional optimisations? I assume loop filtering takes a lot of time... Carl Eugen
Hi, On Jul 4, 2010, at 2:30 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
Kostya <kostya.shishkov <at> gmail.com> writes:
It seems this got lost?
probably it just slipped past me - I was visiting my homeland then
If it still works then ok.
I'd like to add two comments:
Is there any indication that the C-version of the loop-filter is bit- exact? Am I correct that if not, this patch would not improve things?
And since I consider this a more important codec than VP8: Could this be truly reviewed to see possible additional optimisations? I assume loop filtering takes a lot of time...
I can review but you need to give me a week or so and poke me repeatedly. I cannot teview this today or in a few seconds... Also ask Jason or Loren. Ronald
On Jul 4, 2010, at 5:02 PM, Ronald S. Bultje wrote:
Hi,
On Jul 4, 2010, at 2:30 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
Kostya <kostya.shishkov <at> gmail.com> writes:
It seems this got lost?
probably it just slipped past me - I was visiting my homeland then
If it still works then ok.
I'd like to add two comments:
Is there any indication that the C-version of the loop-filter is bit-exact? Am I correct that if not, this patch would not improve things?
And since I consider this a more important codec than VP8: Could this be truly reviewed to see possible additional optimisations? I assume loop filtering takes a lot of time...
I can review but you need to give me a week or so and poke me repeatedly. I cannot teview this today or in a few seconds...
Also ask Jason or Loren.
Updated to patch cleanly, compile, and added mmx/sse2 versions
On Mon, Jul 05, 2010 at 01:44:18AM -0400, David Conrad wrote:
On Jul 4, 2010, at 5:02 PM, Ronald S. Bultje wrote:
Hi,
On Jul 4, 2010, at 2:30 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
Kostya <kostya.shishkov <at> gmail.com> writes:
It seems this got lost?
probably it just slipped past me - I was visiting my homeland then
If it still works then ok.
I'd like to add two comments:
Is there any indication that the C-version of the loop-filter is bit-exact? Am I correct that if not, this patch would not improve things?
And since I consider this a more important codec than VP8: Could this be truly reviewed to see possible additional optimisations? I assume loop filtering takes a lot of time...
I can review but you need to give me a week or so and poke me repeatedly. I cannot teview this today or in a few seconds...
Also ask Jason or Loren.
Updated to patch cleanly, compile, and added mmx/sse2 versions
ok if there're no objections from our x86 SIMD guys
On Jul 5, 2010, at 3:06 AM, Kostya wrote:
On Mon, Jul 05, 2010 at 01:44:18AM -0400, David Conrad wrote:
On Jul 4, 2010, at 5:02 PM, Ronald S. Bultje wrote:
Hi,
On Jul 4, 2010, at 2:30 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
Kostya <kostya.shishkov <at> gmail.com> writes:
It seems this got lost?
probably it just slipped past me - I was visiting my homeland then
If it still works then ok.
I'd like to add two comments:
Is there any indication that the C-version of the loop-filter is bit-exact? Am I correct that if not, this patch would not improve things?
And since I consider this a more important codec than VP8: Could this be truly reviewed to see possible additional optimisations? I assume loop filtering takes a lot of time...
I can review but you need to give me a week or so and poke me repeatedly. I cannot teview this today or in a few seconds...
Also ask Jason or Loren.
Updated to patch cleanly, compile, and added mmx/sse2 versions
ok if there're no objections from our x86 SIMD guys
Applied
Hi, On Mon, Jul 5, 2010 at 1:44 AM, David Conrad <lessen42 at gmail.com> wrote:
Updated to patch cleanly, compile, and added mmx/sse2 versions [..] +SECTION_RODATA +pw_4: times 8 dw 4 +pw_5: times 8 dw 5
cextern pw_4, pw_5 (i.e. use the ones in dsputil_mmx.c) maybe?
+; low, high (src), zero +%macro UNPACK2 4 + mova m%2, m%3 + punpckh%1 m%3, m%4 + punpckl%1 m%2, m%4 +%endmacro
duplicate of SBUTTERFLY in x86util.asm, maybe?
+%macro STORE_4_WORDS_MMX 6 + movd %6, %5 +%if mmsize==16 + psrldq %5, 4 +%else + psrlq %5, 32 +%endif + mov %1, %6w + shr %6, 16 + mov %2, %6w + movd %6, %5 + mov %3, %6w + shr %6, 16 + mov %4, %6w +%endmacro
For VP8 H loopfilter, I save the neighbouring two rows (p1/q1) and write the four out as dwords using movd at once from the mm register, have you tried that (I'm not asking you to rewrite it if you didn't), and if so, is it faster? (I suppose this isn't very practical because of the SSE4 version below...)
+%macro STORE_4_WORDS_SSE4 6 + pextrw %1, %5, %6+0 + pextrw %2, %5, %6+1 + pextrw %3, %5, %6+2 + pextrw %4, %5, %6+3 +%endmacro [..]
+%macro VC1_H_LOOP_FILTER 1-2 + movq m0, [r0 -4] + movq m1, [r0+ r1-4] + movq m2, [r0+2*r1-4] + movq m3, [r0+ r3-4] +%if %1 > 4 + movq m4, [r4 -4] + movq m5, [r4+ r1-4] + movq m6, [r4+2*r1-4] + movq m7, [r4+ r3-4] + punpcklbw m0, m1 + punpcklbw m2, m3 + punpcklbw m4, m5 + punpcklbw m6, m7 + SWAP 1, 2 + SWAP 2, 4 + SWAP 3, 6 + SBUTTERFLY wd, 0, 1, 4 + SBUTTERFLY wd, 2, 3, 4 + SBUTTERFLY dq, 0, 2, 4 + SBUTTERFLY dq, 1, 3, 4 +%else + SBUTTERFLY bw, 0, 1, 4 + SBUTTERFLY bw, 2, 3, 4 + SBUTTERFLY wd, 0, 2, 4 + SBUTTERFLY wd, 1, 3, 4 +%endif
TRANSPOSE4x4W, TRANSPOSE4x4B?
+cglobal vc1_h_loop_filter8_sse4, 3,5,8
Should this (and others like it) be under #ifdef X86_64? I got compile errors if I tried to use xmm8-15 on x86_32. Ronald
On Mon, Jul 5, 2010 at 1:30 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
Hi,
On Mon, Jul 5, 2010 at 1:44 AM, David Conrad <lessen42 at gmail.com> wrote:
Updated to patch cleanly, compile, and added mmx/sse2 versions [..] +SECTION_RODATA +pw_4: times 8 dw 4 +pw_5: times 8 dw 5
cextern pw_4, pw_5 (i.e. use the ones in dsputil_mmx.c) maybe?
+; low, high (src), zero +%macro UNPACK2 4 + ? ?mova ? ? ?m%2, m%3 + ? ?punpckh%1 m%3, m%4 + ? ?punpckl%1 m%2, m%4 +%endmacro
duplicate of SBUTTERFLY in x86util.asm, maybe?
+%macro STORE_4_WORDS_MMX 6 + ? ?movd ? %6, %5 +%if mmsize==16 + ? ?psrldq %5, 4 +%else + ? ?psrlq ?%5, 32 +%endif + ? ?mov ? ?%1, %6w + ? ?shr ? ?%6, 16 + ? ?mov ? ?%2, %6w + ? ?movd ? %6, %5 + ? ?mov ? ?%3, %6w + ? ?shr ? ?%6, 16 + ? ?mov ? ?%4, %6w +%endmacro
For VP8 H loopfilter, I save the neighbouring two rows (p1/q1) and write the four out as dwords using movd at once from the mm register, have you tried that (I'm not asking you to rewrite it if you didn't), and if so, is it faster?
(I suppose this isn't very practical because of the SSE4 version below...)
+%macro STORE_4_WORDS_SSE4 6 + ? ?pextrw %1, %5, %6+0 + ? ?pextrw %2, %5, %6+1 + ? ?pextrw %3, %5, %6+2 + ? ?pextrw %4, %5, %6+3 +%endmacro [..]
I don't recall pextrw being SSE4... Dark Shikari
Hi, On Mon, Jul 5, 2010 at 5:02 PM, Jason Garrett-Glaser <darkshikari at gmail.com> wrote:
On Mon, Jul 5, 2010 at 1:30 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
On Mon, Jul 5, 2010 at 1:44 AM, David Conrad <lessen42 at gmail.com> wrote:
+%macro STORE_4_WORDS_SSE4 6 + ? ?pextrw %1, %5, %6+0 + ? ?pextrw %2, %5, %6+1 + ? ?pextrw %3, %5, %6+2 + ? ?pextrw %4, %5, %6+3 +%endmacro [..]
I don't recall pextrw being SSE4...
Awesome, I should be able to use that for VP8 simple H loopfilter as well (it's mmxext/sse2). Ronald
On Mon, Jul 5, 2010 at 2:04 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
Hi,
On Mon, Jul 5, 2010 at 5:02 PM, Jason Garrett-Glaser <darkshikari at gmail.com> wrote:
On Mon, Jul 5, 2010 at 1:30 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
On Mon, Jul 5, 2010 at 1:44 AM, David Conrad <lessen42 at gmail.com> wrote:
+%macro STORE_4_WORDS_SSE4 6 + ? ?pextrw %1, %5, %6+0 + ? ?pextrw %2, %5, %6+1 + ? ?pextrw %3, %5, %6+2 + ? ?pextrw %4, %5, %6+3 +%endmacro [..]
I don't recall pextrw being SSE4...
Awesome, I should be able to use that for VP8 simple H loopfilter as well (it's mmxext/sse2).
Make sure it's actually faster; do benches on a few CPUs. pextr/pinsr are not always as fast as one wants. Dark Shikari
On Jul 5, 2010, at 5:10 PM, Jason Garrett-Glaser wrote:
On Mon, Jul 5, 2010 at 2:04 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
Hi,
On Mon, Jul 5, 2010 at 5:02 PM, Jason Garrett-Glaser <darkshikari at gmail.com> wrote:
On Mon, Jul 5, 2010 at 1:30 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
On Mon, Jul 5, 2010 at 1:44 AM, David Conrad <lessen42 at gmail.com> wrote:
+%macro STORE_4_WORDS_SSE4 6 + pextrw %1, %5, %6+0 + pextrw %2, %5, %6+1 + pextrw %3, %5, %6+2 + pextrw %4, %5, %6+3 +%endmacro [..]
I don't recall pextrw being SSE4...
Awesome, I should be able to use that for VP8 simple H loopfilter as well (it's mmxext/sse2).
Make sure it's actually faster; do benches on a few CPUs. pextr/pinsr are not always as fast as one wants.
Indeed, iirc pextrw to a register (i.e. pre-sse4) was slower than doing lots of shift+mov
On Jul 5, 2010, at 5:02 PM, Jason Garrett-Glaser wrote:
On Mon, Jul 5, 2010 at 1:30 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
Hi,
On Mon, Jul 5, 2010 at 1:44 AM, David Conrad <lessen42 at gmail.com> wrote:
Updated to patch cleanly, compile, and added mmx/sse2 versions [..] +SECTION_RODATA +pw_4: times 8 dw 4 +pw_5: times 8 dw 5
cextern pw_4, pw_5 (i.e. use the ones in dsputil_mmx.c) maybe?
+; low, high (src), zero +%macro UNPACK2 4 + mova m%2, m%3 + punpckh%1 m%3, m%4 + punpckl%1 m%2, m%4 +%endmacro
duplicate of SBUTTERFLY in x86util.asm, maybe?
+%macro STORE_4_WORDS_MMX 6 + movd %6, %5 +%if mmsize==16 + psrldq %5, 4 +%else + psrlq %5, 32 +%endif + mov %1, %6w + shr %6, 16 + mov %2, %6w + movd %6, %5 + mov %3, %6w + shr %6, 16 + mov %4, %6w +%endmacro
For VP8 H loopfilter, I save the neighbouring two rows (p1/q1) and write the four out as dwords using movd at once from the mm register, have you tried that (I'm not asking you to rewrite it if you didn't), and if so, is it faster?
(I suppose this isn't very practical because of the SSE4 version below...)
+%macro STORE_4_WORDS_SSE4 6 + pextrw %1, %5, %6+0 + pextrw %2, %5, %6+1 + pextrw %3, %5, %6+2 + pextrw %4, %5, %6+3 +%endmacro [..]
I don't recall pextrw being SSE4...
The form with a memory destination is
On Jul 5, 2010, at 4:30 PM, Ronald S. Bultje wrote:
Hi,
On Mon, Jul 5, 2010 at 1:44 AM, David Conrad <lessen42 at gmail.com> wrote:
Updated to patch cleanly, compile, and added mmx/sse2 versions [..] +SECTION_RODATA +pw_4: times 8 dw 4 +pw_5: times 8 dw 5
cextern pw_4, pw_5 (i.e. use the ones in dsputil_mmx.c) maybe?
This doesn't cause non-PIC problems on x86-64? I remember something similar causing a problem in libvpx. Well, if it's problematic vp8dsp.asm has it already so changed.
+; low, high (src), zero +%macro UNPACK2 4 + mova m%2, m%3 + punpckh%1 m%3, m%4 + punpckl%1 m%2, m%4 +%endmacro
duplicate of SBUTTERFLY in x86util.asm, maybe?
Not quite conceptually: this is intended to expand one vector from 8-bit to 16-bit, whereas SBUTTERFLY is intended to merge 2 vectors. The SWAP of SBUTTERFLY in particular will send the constant 0 vector all over the place. I could implement it by calling SBUTTERFLY but IMO it should be a different macro.
+%macro STORE_4_WORDS_MMX 6 + movd %6, %5 +%if mmsize==16 + psrldq %5, 4 +%else + psrlq %5, 32 +%endif + mov %1, %6w + shr %6, 16 + mov %2, %6w + movd %6, %5 + mov %3, %6w + shr %6, 16 + mov %4, %6w +%endmacro
For VP8 H loopfilter, I save the neighbouring two rows (p1/q1) and write the four out as dwords using movd at once from the mm register, have you tried that (I'm not asking you to rewrite it if you didn't), and if so, is it faster?
I just tried doing it this way, and it seems to be a little slower. I'll try using STORE_4_WORDS_MMX in vp8's simple loop filter later, but not soon.
(I suppose this isn't very practical because of the SSE4 version below...)
+%macro STORE_4_WORDS_SSE4 6 + pextrw %1, %5, %6+0 + pextrw %2, %5, %6+1 + pextrw %3, %5, %6+2 + pextrw %4, %5, %6+3 +%endmacro [..]
+%macro VC1_H_LOOP_FILTER 1-2 + movq m0, [r0 -4] + movq m1, [r0+ r1-4] + movq m2, [r0+2*r1-4] + movq m3, [r0+ r3-4] +%if %1 > 4 + movq m4, [r4 -4] + movq m5, [r4+ r1-4] + movq m6, [r4+2*r1-4] + movq m7, [r4+ r3-4] + punpcklbw m0, m1 + punpcklbw m2, m3 + punpcklbw m4, m5 + punpcklbw m6, m7 + SWAP 1, 2 + SWAP 2, 4 + SWAP 3, 6 + SBUTTERFLY wd, 0, 1, 4 + SBUTTERFLY wd, 2, 3, 4 + SBUTTERFLY dq, 0, 2, 4 + SBUTTERFLY dq, 1, 3, 4 +%else + SBUTTERFLY bw, 0, 1, 4 + SBUTTERFLY bw, 2, 3, 4 + SBUTTERFLY wd, 0, 2, 4 + SBUTTERFLY wd, 1, 3, 4 +%endif
TRANSPOSE4x4W, TRANSPOSE4x4B?
Fixed.
+cglobal vc1_h_loop_filter8_sse4, 3,5,8
Should this (and others like it) be under #ifdef X86_64? I got compile errors if I tried to use xmm8-15 on x86_32.
What compiler errors are you getting? This shouldn't use xmm8+ ever.
Hi, On Jul 5, 2010, at 11:34 PM, David Conrad <lessen42 at gmail.com> wrote:
On Jul 5, 2010, at 4:30 PM, Ronald S. Bultje wrote:
On Mon, Jul 5, 2010 at 1:44 AM, David Conrad <lessen42 at gmail.com> wrote:
Updated to patch cleanly, compile, and added mmx/sse2 versions [..] +SECTION_RODATA +pw_4: times 8 dw 4 +pw_5: times 8 dw 5
cextern pw_4, pw_5 (i.e. use the ones in dsputil_mmx.c) maybe?
This doesn't cause non-PIC problems on x86-64? I remember something similar causing a problem in libvpx.
Only if using const+offset. It's fine when only deref'ing [const].
+cglobal vc1_h_loop_filter8_sse4, 3,5,8
Should this (and others like it) be under #ifdef X86_64? I got compile errors if I tried to use xmm8-15 on x86_32.
What compiler errors are you getting? This shouldn't use xmm8+ ever.
The ,8 at the end saves xmm8-15. Xmm0-7 are free to use. You can probably remove it unless I'm wrong (very well possible). Ronald
On Tue, 6 Jul 2010, Ronald S. Bultje wrote:
On Jul 5, 2010, at 11:34 PM, David Conrad <lessen42 at gmail.com> wrote:
On Jul 5, 2010, at 4:30 PM, Ronald S. Bultje wrote:
+cglobal vc1_h_loop_filter8_sse4, 3,5,8
Should this (and others like it) be under #ifdef X86_64? I got compile errors if I tried to use xmm8-15 on x86_32.
What compiler errors are you getting? This shouldn't use xmm8+ ever.
The ,8 at the end saves xmm8-15. Xmm0-7 are free to use. You can probably remove it unless I'm wrong (very well possible).
The ,8 says that it uses 8 xmmregs, namely xmm0-xmm7. Which does nothing at all on x86_32, since all xmms are caller-saved under x86_32 abi, but is needed for win64. --Loren Merritt
Hi, On Tue, Jul 6, 2010 at 11:15 AM, Loren Merritt <lorenm at u.washington.edu> wrote:
On Tue, 6 Jul 2010, Ronald S. Bultje wrote:
On Jul 5, 2010, at 11:34 PM, David Conrad <lessen42 at gmail.com> wrote:
On Jul 5, 2010, at 4:30 PM, Ronald S. Bultje wrote:
+cglobal vc1_h_loop_filter8_sse4, 3,5,8
Should this (and others like it) be under #ifdef X86_64? I got compile errors if I tried to use xmm8-15 on x86_32.
What compiler errors are you getting? This shouldn't use xmm8+ ever.
The ,8 at the end saves xmm8-15. Xmm0-7 are free to use. You can probably remove it unless I'm wrong (very well possible).
The ,8 says that it uses 8 xmmregs, namely xmm0-xmm7. Which does nothing at all on x86_32, since all xmms are caller-saved under x86_32 abi, but is needed for win64.
Oh! So I should do this even if it's <=8? Ronald
On Tue, 6 Jul 2010, Ronald S. Bultje wrote:
On Tue, Jul 6, 2010 at 11:15 AM, Loren Merritt <lorenm at u.washington.edu> wrote:
The ,8 says that it uses 8 xmmregs, namely xmm0-xmm7. Which does nothing at all on x86_32, since all xmms are caller-saved under x86_32 abi, but is needed for win64.
Oh! So I should do this even if it's <=8?
You should specify it if it's >=7. --Loren Merritt
On Jul 4, 2010, at 2:30 PM, Carl Eugen Hoyos wrote:
Kostya <kostya.shishkov <at> gmail.com> writes:
It seems this got lost?
probably it just slipped past me - I was visiting my homeland then
If it still works then ok.
I'd like to add two comments:
Is there any indication that the C-version of the loop-filter is bit-exact? Am I correct that if not, this patch would not improve things?
IIRC the loop filter C code is correct, but the rules for applying it are rather convoluted and not implemented quite right for P frames. Looks like I lost the fixes for I/B frames too, attached...
And since I consider this a more important codec than VP8: Could this be truly reviewed to see possible additional optimisations? I assume loop filtering takes a lot of time...
On Mon, Jul 05, 2010 at 12:11:30AM -0400, David Conrad wrote:
On Jul 4, 2010, at 2:30 PM, Carl Eugen Hoyos wrote:
Kostya <kostya.shishkov <at> gmail.com> writes:
It seems this got lost?
probably it just slipped past me - I was visiting my homeland then
If it still works then ok.
I'd like to add two comments:
Is there any indication that the C-version of the loop-filter is bit-exact? Am I correct that if not, this patch would not improve things?
IIRC the loop filter C code is correct, but the rules for applying it are rather convoluted and not implemented quite right for P frames.
Could be. BTW, P-frame loop filter order also differs in old not (yet) supported WMV3.
Looks like I lost the fixes for I/B frames too, attached...
And since I consider this a more important codec than VP8: Could this be truly reviewed to see possible additional optimisations? I assume loop filtering takes a lot of time...
Commit ff_draw_horiz_band() first separately, otherwise it's OK for me.
On Jul 5, 2010, at 12:55 AM, Kostya wrote:
On Mon, Jul 05, 2010 at 12:11:30AM -0400, David Conrad wrote:
On Jul 4, 2010, at 2:30 PM, Carl Eugen Hoyos wrote:
Kostya <kostya.shishkov <at> gmail.com> writes:
It seems this got lost?
probably it just slipped past me - I was visiting my homeland then
If it still works then ok.
I'd like to add two comments:
Is there any indication that the C-version of the loop-filter is bit-exact? Am I correct that if not, this patch would not improve things?
IIRC the loop filter C code is correct, but the rules for applying it are rather convoluted and not implemented quite right for P frames.
Could be. BTW, P-frame loop filter order also differs in old not (yet) supported WMV3.
Looks like I lost the fixes for I/B frames too, attached...
And since I consider this a more important codec than VP8: Could this be truly reviewed to see possible additional optimisations? I assume loop filtering takes a lot of time...
Commit ff_draw_horiz_band() first separately, otherwise it's OK for me.
Done and applied. The fate test spec will have to be updated. It's still not exact to the reference, but the errors are a little less now.
participants (7)
-
cehoyos＠ag.or.at -
darkshikari＠gmail.com -
kostya.shishkov＠gmail.com -
lessen42＠gmail.com -
lorenm＠u.washington.edu -
Reimar.Doeffinger＠gmx.de -
rsbultje＠gmail.com