Shiyou Yin: > > >> 2022年9月11日 10:06，Shiyou Yin <yinshiyou...@loongson.cn> 写道： >> >> >> >>> 2022年9月9日 21:11，Andreas Rheinhardt <andreas.rheinha...@outlook.com >>> <mailto:andreas.rheinha...@outlook.com>> 写道： >>> >>> Shiyou Yin: >>>> >>>> >>>>> 2022年9月6日 16:12，Shiyou Yin <yinshiyou...@loongson.cn >>>>> <mailto:yinshiyou...@loongson.cn>> 写道： >>>>> >>>>>> >>>>>> 2022年8月29日 20:30，Andreas Rheinhardt <andreas.rheinha...@outlook.com >>>>>> <mailto:andreas.rheinha...@outlook.com> >>>>>> <mailto:andreas.rheinha...@outlook.com >>>>>> <mailto:andreas.rheinha...@outlook.com>>> 写道： >>>>>> >>>>>> Hao Chen: >>>>>>> ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -s 640x480 >>>>>>> -pix_fmt >>>>>>> rgb24 -y /dev/null -an >>>>>>> before: 150fps >>>>>>> after: 183fps >>>>>>> >>>>>>> Signed-off-by: Hao Chen <chen...@loongson.cn >>>>>>> <mailto:chen...@loongson.cn>> >>>>>>> --- >>>>>>> libswscale/loongarch/Makefile | 3 +- >>>>>>> libswscale/loongarch/output_lasx.c | 1982 +++++++++++++++++ >>>>>>> libswscale/loongarch/swscale_init_loongarch.c | 3 + >>>>>>> libswscale/loongarch/swscale_loongarch.h | 6 + >>>>>>> 4 files changed, 1993 insertions(+), 1 deletion(-) >>>>>>> create mode 100644 libswscale/loongarch/output_lasx.c >>>>>>> >>>> >>>>>>> +static void >>>>>>> +yuv2rgb_2_template_lasx(SwsContext *c, const int16_t *buf[2], >>>>>>> + const int16_t *ubuf[2], const int16_t *vbuf[2], >>>>>>> + const int16_t *abuf[2], uint8_t *dest, int dstW, >>>>>>> + int yalpha, int uvalpha, int y, >>>>>>> + enum AVPixelFormat target, int hasAlpha) >>>>>>> +{ >>>>>>> + const int16_t *buf0 = buf[0], *buf1 = buf[1], >>>>>>> + *ubuf0 = ubuf[0], *ubuf1 = ubuf[1], >>>>>>> + *vbuf0 = vbuf[0], *vbuf1 = vbuf[1]; >>>>>>> + int yalpha1 = 4096 - yalpha; >>>>>>> + int uvalpha1 = 4096 - uvalpha; >>>>>>> + int i, count = 0; >>>>>>> + int len = dstW - 15; >>>>>>> + int len_count = (dstW + 1) >> 1; >>>>>>> + const void *r, *g, *b; >>>>>>> + int head = YUVRGB_TABLE_HEADROOM; >>>>>>> + __m256i v_yalpha1 = __lasx_xvreplgr2vr_w(yalpha1); >>>>>>> + __m256i v_uvalpha1 = __lasx_xvreplgr2vr_w(uvalpha1); >>>>>>> + __m256i v_yalpha = __lasx_xvreplgr2vr_w(yalpha); >>>>>>> + __m256i v_uvalpha = __lasx_xvreplgr2vr_w(uvalpha); >>>>>>> + __m256i headroom = __lasx_xvreplgr2vr_w(head); >>>>>>> + >>>>>>> + for (i = 0; i < len; i += 16) { >>>>>>> + int Y1, Y2, U, V; >>>>>>> + int i_dex = i << 1; >>>>>>> + int c_dex = count << 1; >>>>>>> + __m256i y0_h, y0_l, y0, u0, v0; >>>>>>> + __m256i y1_h, y1_l, y1, u1, v1; >>>>>>> + __m256i y_l, y_h, u, v; >>>>>>> + >>>>>>> + DUP4_ARG2(__lasx_xvldx, buf0, i_dex, ubuf0, c_dex, vbuf0, c_dex, >>>>>>> + buf1, i_dex, y0, u0, v0, y1); >>>>>>> + DUP2_ARG2(__lasx_xvldx, ubuf1, c_dex, vbuf1, c_dex, u1, v1); >>>>>>> + DUP2_ARG2(__lasx_xvsllwil_w_h, y0, 0, y1, 0, y0_l, y1_l); >>>>>>> + DUP2_ARG1(__lasx_xvexth_w_h, y0, y1, y0_h, y1_h); >>>>>>> + DUP4_ARG1(__lasx_vext2xv_w_h, u0, u1, v0, v1, u0, u1, v0, v1); >>>>>>> + y0_l = __lasx_xvmul_w(y0_l, v_yalpha1); >>>>>>> + y0_h = __lasx_xvmul_w(y0_h, v_yalpha1); >>>>>>> + u0 = __lasx_xvmul_w(u0, v_uvalpha1); >>>>>>> + v0 = __lasx_xvmul_w(v0, v_uvalpha1); >>>>>>> + y_l = __lasx_xvmadd_w(y0_l, v_yalpha, y1_l); >>>>>>> + y_h = __lasx_xvmadd_w(y0_h, v_yalpha, y1_h); >>>>>>> + u = __lasx_xvmadd_w(u0, v_uvalpha, u1); >>>>>>> + v = __lasx_xvmadd_w(v0, v_uvalpha, v1); >>>>>>> + y_l = __lasx_xvsrai_w(y_l, 19); >>>>>>> + y_h = __lasx_xvsrai_w(y_h, 19); >>>>>>> + u = __lasx_xvsrai_w(u, 19); >>>>>>> + v = __lasx_xvsrai_w(v, 19); >>>>>>> + u = __lasx_xvadd_w(u, headroom); >>>>>>> + v = __lasx_xvadd_w(v, headroom); >>>>>>> + WRITE_YUV2RGB(y_l, y_l, u, v, 0, 1, 0, 0); >>>>>>> + WRITE_YUV2RGB(y_l, y_l, u, v, 2, 3, 1, 1); >>>>>>> + WRITE_YUV2RGB(y_h, y_h, u, v, 0, 1, 2, 2); >>>>>>> + WRITE_YUV2RGB(y_h, y_h, u, v, 2, 3, 3, 3); >>>>>>> + WRITE_YUV2RGB(y_l, y_l, u, v, 4, 5, 4, 4); >>>>>>> + WRITE_YUV2RGB(y_l, y_l, u, v, 6, 7, 5, 5); >>>>>>> + WRITE_YUV2RGB(y_h, y_h, u, v, 4, 5, 6, 6); >>>>>>> + WRITE_YUV2RGB(y_h, y_h, u, v, 6, 7, 7, 7); >>>>>>> + } >>>>>>> + if (dstW - i >= 8) { >>>>>>> + int Y1, Y2, U, V; >>>>>>> + int i_dex = i << 1; >>>>>>> + __m256i y0_l, y0, u0, v0; >>>>>>> + __m256i y1_l, y1, u1, v1; >>>>>>> + __m256i y_l, u, v; >>>>>>> + >>>>>>> + y0 = __lasx_xvldx(buf0, i_dex); >>>>>> >>>>>> 1. Not long ago, I tried to constify the src pointer of several asm >>>>>> functions and noticed that they produced new warnings for loongarch >>>>>> (according to patchwork: >>>>>> https://patchwork.ffmpeg.org/project/ffmpeg/patch/db6pr0101mb2214178d3e6b8dca5b86f8198f...@db6pr0101mb2214.eurprd01.prod.exchangelabs.com/ >>>>>> >>>>>> <https://patchwork.ffmpeg.org/project/ffmpeg/patch/db6pr0101mb2214178d3e6b8dca5b86f8198f...@db6pr0101mb2214.eurprd01.prod.exchangelabs.com/>), >>>>>> even though I was sure that the code is const-correct. After finding >>>>>> (via https://github.com/opencv/opencv/pull/21833 >>>>>> <https://github.com/opencv/opencv/pull/21833>) a toolchain >>>>>> (https://gitee.com/wenux/cross-compiler-la-on-x86 >>>>>> <https://gitee.com/wenux/cross-compiler-la-on-x86>) that can build the >>>>>> lasx and lsx code (upstream GCC seems to be lacking lsx and lasx support >>>>>> at the moment; at least, my self-compiled loongarch-GCC did not support >>>>>> lsx and lasx) the issue was clear: lsxintrin.h and lasxintrin.h do not >>>>>> use const at all, even for functions that only read data (I presume the >>>>>> vl in __lsx_vldx stands for "vector load"?). >>>>>> So I sent another iteration >>>>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299562.html >>>>>> <https://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299562.html> of >>>>>> that patchset that now added wrappers for __lsx_vldx() and >>>>>> __lasx_xvldx() and cc'ed you and some other developers from loongson to >>>>>> alert you of the issue in the hope that you fix the headers, so that my >>>>>> wrappers wouldn't need to be applied. That didn't work, as my mails >>>>>> could not be delivered to you. So I applied the patchset. >>>>>> 2. You use __lasx_xvldx() to read from a const int16_t. This will give >>>>>> new warnings unless the above issue has been fixed. Has it? >>>>>> 3. I don't know whether it has, as patchwork's fate tests don't work for >>>>>> a few days already. Given that the mails I receive from patchwork when >>>>>> it doesn't like a commit message arrive from "Patchwork >>>>>> <yinshiyou...@loongson.cn <mailto:yinshiyou...@loongson.cn>>" I presume >>>>>> that loongson is now somehow >>>>>> running patchwork, so you should be able to inform the right people to >>>>>> fix it. >>>>>> 4. If you fixed the const-issue, can you please make an updated >>>>>> toolchain with lsx and lasx support enabled available to us? >>>>>> >>>>>> - Andreas >>>>>> >>>>> >>>>> Hi Andreas, >>>>> >>>>> Sorry for the late reply. >>>>> This issue will be fixed by using const for v1 of __lsx_vldx, and I will >>>>> update toolchain of LoongArch patchwork runner ASAP. >>>>> Thank you very much for analyzing this problem and giving suggestion. >>>>> >>>>> Thanks, >>>>> Shiyou >>>> >>>> Hi Andreas, >>>> Has updated patchwork runner environment, you can revert the patchset >>>> which add wrappers for __lsx_[x]vldx. >>>> >>> >>> Just sent the patches: >>> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-September/301201.html >>> <https://ffmpeg.org/pipermail/ffmpeg-devel/2022-September/301201.html> >>> Can you provide an updated toolchain (with x86 host) able to compile lsx >>> and lasx? >>> >>> - Andreas >> >> Compiler team haven’t release this version yet(maybe at Sep 13), you can >> check here : >> http://ftp.loongnix.cn/toolchain/gcc/release/loongarch/gcc8/ >> <http://ftp.loongnix.cn/toolchain/gcc/release/loongarch/gcc8/> >> If you want to try it now, you can update attachment file first. >> >> > toolchain has been uploaded to > http://ftp.loongnix.cn/toolchain/gcc/release/loongarch/gcc8/ > <http://ftp.loongnix.cn/toolchain/gcc/release/loongarch/gcc8/> > loongson-gnu-toolchain-8.3-src-loongarch64-linux-gnu-rc1.1.tar > <http://ftp.loongnix.cn/toolchain/gcc/release/loongarch/gcc8/loongson-gnu-toolchain-8.3-src-loongarch64-linux-gnu-rc1.1.tar> > > loongson-gnu-toolchain-8.3-x86_64-loongarch64-linux-gnu-rc1.1.tar.xz > <http://ftp.loongnix.cn/toolchain/gcc/release/loongarch/gcc8/loongson-gnu-toolchain-8.3-x86_64-loongarch64-linux-gnu-rc1.1.tar.xz> > loongson-gnu-toolchain-8.3-x86_64-loongarch64-linux-gnu-rc1.1.tar.xz.md5 > <http://ftp.loongnix.cn/toolchain/gcc/release/loongarch/gcc8/loongson-gnu-toolchain-8.3-x86_64-loongarch64-linux-gnu-rc1.1.tar.xz.md5> > > > Thanks, > Shiyou
Yes, I have already noticed this and have therefore already reverted my wrapper patches. Thanks. - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
