[x265] [PATCH] asm: fix sse_pp[32x64] sse2 asm for 12 bit
chen
chenm003 at 163.com
Wed Sep 9 16:50:31 CEST 2015
At 2015-09-09 11:59:40,ramya at multicorewareinc.com wrote:
># HG changeset patch
># User Ramya Sriraman <ramya at multicorewareinc.com>
># Date 1441771057 -19800
># Wed Sep 09 09:27:37 2015 +0530
># Node ID b155831be382e67832b554fa24b3ee65e793a4d7
># Parent f622f46b2ce87d6f30d937de79c1de94a5d0ee54
>asm: fix sse_pp[32x64] sse2 asm for 12 bit
>
>diff -r f622f46b2ce8 -r b155831be382 source/common/x86/asm-primitives.cpp
>--- a/source/common/x86/asm-primitives.cpp Wed Aug 26 17:06:25 2015 +0530
>+++ b/source/common/x86/asm-primitives.cpp Wed Sep 09 09:27:37 2015 +0530
>@@ -1000,11 +1000,10 @@
> p.chroma[X265_CSP_I422].cu[BLOCK_422_4x8].sse_pp = (pixel_sse_t)PFX(pixel_ssd_ss_4x8_mmx2);
> p.chroma[X265_CSP_I422].cu[BLOCK_422_8x16].sse_pp = (pixel_sse_t)PFX(pixel_ssd_ss_8x16_sse2);
> p.chroma[X265_CSP_I422].cu[BLOCK_422_16x32].sse_pp = (pixel_sse_t)PFX(pixel_ssd_ss_16x32_sse2);
>-
>+ p.chroma[X265_CSP_I422].cu[BLOCK_422_32x64].sse_pp = (pixel_sse_t)PFX(pixel_ssd_ss_32x64_sse2);
> #if X265_DEPTH <= 10
> p.cu[BLOCK_4x4].sse_ss = PFX(pixel_ssd_ss_4x4_mmx2);
> ALL_LUMA_CU(sse_ss, pixel_ssd_ss, sse2);
>- p.chroma[X265_CSP_I422].cu[BLOCK_422_32x64].sse_pp = (pixel_sse_t)PFX(pixel_ssd_ss_32x64_sse2);
> #endif
> p.cu[BLOCK_4x4].dct = PFX(dct4_sse2);
> p.cu[BLOCK_8x8].dct = PFX(dct8_sse2);
>diff -r f622f46b2ce8 -r b155831be382 source/common/x86/ssd-a.asm
>--- a/source/common/x86/ssd-a.asm Wed Aug 26 17:06:25 2015 +0530
>+++ b/source/common/x86/ssd-a.asm Wed Sep 09 09:27:37 2015 +0530
>@@ -125,6 +125,59 @@
> RET
> %endmacro
>
>+
>+; Function to find ssd for 32x16 block, sse2, 12 bit depth
>+; Defined sepeartely to be called from SSD_ONE_32 macro
>+INIT_XMM sse2
>+cglobal ssd_ss_32x16
>+ pxor m8, m8
>+ mov r4d, 16
>+.loop:
>+ movu m0, [r0]
>+ movu m1, [r0+mmsize]
>+ movu m2, [r0+2*mmsize]
>+ movu m3, [r0+3*mmsize]
>+ psubw m0, [r2]
>+ psubw m1, [r2+mmsize]
>+ psubw m2, [r2+2*mmsize]
>+ psubw m3, [r2+3*mmsize]
sorry for last comment, I means we need analyze address value, I check it again, the function just call from estimateResidualQT(), in there, both address may unaligned, so we need verify it more on 12bpp mode
>+ lea r0, [r0+r1]
>+ lea r2, [r2+r3]
>+ pmaddwd m0, m0
>+ pmaddwd m1, m1
>+ pmaddwd m2, m2
>+ pmaddwd m3, m3
>+ paddd m2, m3
>+ paddd m0, m1
>+ paddd m0, m2
>+ paddd m8, m0
>+ dec r4d
>+ jnz .loop
>+
>+ mova m4, m8
>+ pxor m5, m5
>+ punpckldq m8, m5
>+ punpckhdq m4, m5
>+ paddq m4, m8
>+ movhlps m5, m4
>+ paddq m4, m5
>+ paddq m9, m4
>+ ret
>+
>+%macro SSD_ONE_32 0
>+cglobal pixel_ssd_ss_32x64, 4,7,10
>+ add r1, r1
>+ add r3, r3
>+ pxor m9, m9
>+ xor r4, r4
>+ call ssd_ss_32x16
>+ call ssd_ss_32x16
>+ call ssd_ss_32x16
>+ call ssd_ss_32x16
>+ movq rax, m9
>+ RET
>+%endmacro
>+
> %macro SSD_TWO 2
> cglobal pixel_ssd_ss_%1x%2, 4,7,8
> FIX_STRIDES r1, r3
>@@ -468,7 +521,13 @@
> SSD_ONE 32, 16
> SSD_ONE 32, 24
> SSD_ONE 32, 32
>-SSD_ONE 32, 64
>+
>+%if BIT_DEPTH <= 10
>+ SSD_ONE 32, 64
>+%else
>+ SSD_ONE_32
>+%endif
>+
> SSD_TWO 48, 64
> SSD_TWO 64, 16
> SSD_TWO 64, 32
>_______________________________________________
>x265-devel mailing list
>x265-devel at videolan.org
>https://mailman.videolan.org/listinfo/x265-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20150909/a4df4581/attachment.html>
More information about the x265-devel
mailing list