[x265] [PATCH 2 of 2] asm:intra pred planar32 sse2 high bit
chen
chenm003 at 163.com
Tue Mar 10 00:09:50 CET 2015
At 2015-03-10 07:06:26,dave <dtyx265 at gmail.com> wrote:
On 03/09/2015 03:23 PM, chen wrote:
At 2015-03-10 05:24:09,dtyx265 at gmail.com wrote:
># HG changeset patch
># User David T Yuen <dtyx265 at gmail.com>
># Date 1425935926 25200
># Node ID 4d1d54d28cb1635448ceec764c793d1b37cef7a4
># Parent ef383507c21ca704b58e759e440f4ae2e177c499
>asm:intra pred planar32 sse2 high bit
>
>This replaces c code for systems using ssse3 to sse2 processors
>The code is backported from intrapred planar32 sse4
>
>Unlike the sse4 high bit version which operates with 32-bit values
>this version uses 16-bits to calculate the prediction. 16-bits
>is just enough for 10 bit luma depth, or at least it's enough for
>the testbench. Anything more and this primitive could overflow.
>
>./test/TestBench --testbench intrapred | grep intra_planar_32x32
>intra_planar_32x32 13.80x 8289.69 114379.01
>
>diff -r ef383507c21c -r 4d1d54d28cb1 source/common/x86/asm-primitives.cpp
>--- a/source/common/x86/asm-primitives.cpp Mon Mar 09 13:50:57 2015 -0700
>+++ b/source/common/x86/asm-primitives.cpp Mon Mar 09 14:18:46 2015 -0700
>@@ -876,6 +876,7 @@
> p.cu[BLOCK_4x4].intra_pred[PLANAR_IDX] = x265_intra_pred_planar4_sse2;
> p.cu[BLOCK_8x8].intra_pred[PLANAR_IDX] = x265_intra_pred_planar8_sse2;
> p.cu[BLOCK_16x16].intra_pred[PLANAR_IDX] = x265_intra_pred_planar16_sse2;
>+ p.cu[BLOCK_32x32].intra_pred[PLANAR_IDX] = x265_intra_pred_planar32_sse2;
>
> p.cu[BLOCK_4x4].sse_ss = x265_pixel_ssd_ss_4x4_mmx2;
> ALL_LUMA_CU(sse_ss, pixel_ssd_ss, sse2);
>diff -r ef383507c21c -r 4d1d54d28cb1 source/common/x86/intrapred16.asm
>--- a/source/common/x86/intrapred16.asm Mon Mar 09 13:50:57 2015 -0700
>+++ b/source/common/x86/intrapred16.asm Mon Mar 09 14:18:46 2015 -0700
>@@ -65,6 +65,10 @@
> pw_planar16_1: dw 15, 15, 15, 15, 15, 15, 15, 15
> pd_planar32_1: dd 31, 31, 31, 31
>
>+pw_planar32_1: dw 31, 31, 31, 31, 31, 31, 31, 31
>+pw_planar32_L: dw 31, 30, 29, 28, 27, 26, 25, 24
>+pw_planar32_H: dw 23, 22, 21, 20, 19, 18, 17, 16
>+
> const planar32_table
> %assign x 31
> %rep 8
>@@ -86,12 +90,15 @@
> cextern pw_4
> cextern pw_8
> cextern pw_16
>+cextern pw_32
> cextern pw_1023
> cextern pd_16
> cextern pd_32
> cextern pw_4096
> cextern multiL
> cextern multiH
>+cextern multiH2
>+cextern multiH3
> cextern multi_2Row
> cextern pw_swap
> cextern pb_unpackwq1
>@@ -575,6 +582,133 @@
> INTRA_PRED_PLANAR_16 15
> RET
>
>+;---------------------------------------------------------------------------------------
>+; void intra_pred_planar(pixel* dst, intptr_t dstStride, pixel*srcPix, int, int filter)
>+;---------------------------------------------------------------------------------------
>+INIT_XMM sse2
>+cglobal intra_pred_planar32, 3,3,13
>+ movd m3, [r2 + 66] ; topRight = above[32]
>+
>+ pshuflw m3, m3, 0x00
>+ pshufd m3, m3, 0x44
>+
>+ pmullw m0, m3, [multiL] ; (x + 1) * topRight
>+ pmullw m1, m3, [multiH] ; (x + 1) * topRight
>+ pmullw m2, m3, [multiH2] ; (x + 1) * topRight
>+ pmullw m3, [multiH3] ; (x + 1) * topRight
>+
>+ movd m6, [r2 + 194] ; bottomLeft = left[32]
>+ pshuflw m6, m6, 0x00
>+ pshufd m6, m6, 0x44
>+ mova m5, m6
>+ paddw m5, [pw_32]
>+
>+ paddw m0, m5
>+ paddw m1, m5
>+ paddw m2, m5
>+ paddw m3, m5
>+ mova m8, m6
>+ mova m9, m6
>+ mova m10, m6
>+
>+ movu m4, [r2 + 2]
>+ psubw m8, m4
>+ pmullw m4, [pw_planar32_1]
>+ paddw m0, m4
>+
>+ movu m5, [r2 + 18]
>+ psubw m9, m5
>+ pmullw m5, [pw_planar32_1]
>+ paddw m1, m5
>+
>+ movu m4, [r2 + 34]
>+ psubw m10, m4
>+ pmullw m4, [pw_planar32_1]
>+ paddw m2, m4
>+
>+ movu m5, [r2 + 50]
>+ psubw m6, m5
>+ pmullw m5, [pw_planar32_1]
the constant use more than 2 times, need buffer into register
>+ paddw m3, m5
>+
>+%macro PROCESS 1
>+ pmullw m5, %1, [pw_planar32_L]
>+ pmullw m11, %1, [pw_planar32_H]
buffer into register
Buffering these constants in registers slows performance on my machine.
./test/TestBench --testbench intrapred | grep intra_planar_32x32
intra_planar_32x32 12.01x 9521.82 114371.95
And no, I didn't set the registers inside the PROCESS macro...
[MC] your code work on x64 platform, you have at least two free register to buffer these constant, it reduce code size and improve performance
>+ paddw m5, m0
>+ paddw m11, m1
>+ psrlw m5, 6
>+ psrlw m11, 6
>+ movu [r0], m5
>+ movu [r0 + 16], m11
>+
>+ pmullw m5, %1, [pw_planar16_0]
>+ pmullw %1, [pw_planar8_0]
>+ paddw m5, m2
>+ paddw %1, m3
>+ psrlw m5, 6
>+ psrlw %1, 6
>+ movu [r0 + 32], m5
>+ movu [r0 + 48], %1
>+%endmacro
>+
>+%macro INCREMENT 0
>+ paddw m2, m10
>+ paddw m3, m6
>+ paddw m0, m8
>+ paddw m1, m9
>+ lea r0, [r0 + r1 * 2]
we have free register, so may buffer r1*2 and replace by ADD to avoid execute port bottleneck
This provides a small performance improvement, I will submit a new patch.
>+%endmacro
>+
>+%assign x 0
>+%rep 4
>+ movu m4, [r2 + 130 + x * 16] ;130 = 32*sizeof(pixel)*2 + 1*sizeof(pixel)
>+
>+ pshuflw m7, m4, 0x00
>+ pshufd m7, m7, 0x44
>+ pshuflw m12, m4, 0x55
>+ pshufd m12, m12, 0x44
>+
>+ PROCESS m7
>+ INCREMENT
>+ PROCESS m12
>+ INCREMENT
>+
>+ pshuflw m7, m4, 0xAA
>+ pshufd m7, m7, 0x44
>+ pshuflw m12, m4, 0xFF
>+ pshufd m12, m12, 0x44
>+
>+ PROCESS m7
>+ INCREMENT
>+ PROCESS m12
>+ INCREMENT
>+
>+ pshufhw m7, m4, 0x00
>+ pshufd m7, m7, 0xEE
>+ pshufhw m12, m4, 0x55
>+ pshufd m12, m12, 0xEE
>+
>+ PROCESS m7
>+ INCREMENT
>+ PROCESS m12
>+ INCREMENT
>+
>+ pshufhw m7, m4, 0xAA
>+ pshufd m7, m7, 0xEE
>+ pshufhw m12, m4, 0xFF
>+ pshufd m12, m12, 0xEE
>+
>+ PROCESS m7
>+ INCREMENT
>+ PROCESS m12
>+
>+ %if x < 3
>+ INCREMENT
>+ %endif
>+%assign x x+1
>+%endrep
>+ RET
>+
> ;-----------------------------------------------------------------------------------
> ; void intra_pred_dc(pixel* dst, intptr_t dstStride, pixel* above, int, int filter)
> ;-----------------------------------------------------------------------------------
>_______________________________________________
>x265-devel mailing list
>x265-devel at videolan.org
>https://mailman.videolan.org/listinfo/x265-devel
_______________________________________________
x265-devel mailing list
x265-devel at videolan.orghttps://mailman.videolan.org/listinfo/x265-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20150310/7f15bbee/attachment-0001.html>
More information about the x265-devel
mailing list