RepoMirrors
/
ffmpeg
mirror of https://git.ffmpeg.org/ffmpeg.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
ffmpeg/libswscale/riscv/rgb2rgb_rvv.S

175 lines
4.2 KiB
ArmAsm
Raw Normal View History

sws/rgb2rgb: RISC-V V shuffle_bytes_xxxx functions
2022-09-28 15:29:59 +00:00
/*
* Copyright © 2022 Rémi Denis-Courmont.
*
* This file is part of FFmpeg.
*
* FFmpeg is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* FFmpeg is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with FFmpeg; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include "libavutil/riscv/asm.S"
func ff_shuffle_bytes_0321_rvv, zve32x
swscale/rgb2rgb2: rework RISC-V V shuffle_bytes_{0321,2103} This avoids strided loads. Before: shuffle_bytes_0321_rvv_i32: 307.7 shuffle_bytes_2103_rvv_i32: 308.7 After: shuffle_bytes_0321_rvv_i32: 59.7 shuffle_bytes_2103_rvv_i32: 61.5
2023-07-18 18:39:59 +00:00
li t1, 0x00ff00ff
j 1f
endfunc
func ff_shuffle_bytes_2103_rvv, zve32x
li t1, ~0x00ff00ff
sws/rgb2rgb: RISC-V V shuffle_bytes_xxxx functions
2022-09-28 15:29:59 +00:00
1:
swscale/rgb2rgb2: rework RISC-V V shuffle_bytes_{0321,2103} This avoids strided loads. Before: shuffle_bytes_0321_rvv_i32: 307.7 shuffle_bytes_2103_rvv_i32: 308.7 After: shuffle_bytes_0321_rvv_i32: 59.7 shuffle_bytes_2103_rvv_i32: 61.5
2023-07-18 18:39:59 +00:00
not t2, t1
sws/rgb2rgb: RISC-V V shuffle_bytes_xxxx functions
2022-09-28 15:29:59 +00:00
srai a2, a2, 2
2:
swscale/rgb2rgb2: rework RISC-V V shuffle_bytes_{0321,2103} This avoids strided loads. Before: shuffle_bytes_0321_rvv_i32: 307.7 shuffle_bytes_2103_rvv_i32: 308.7 After: shuffle_bytes_0321_rvv_i32: 59.7 shuffle_bytes_2103_rvv_i32: 61.5
2023-07-18 18:39:59 +00:00
vsetvli t0, a2, e32, m8, ta, ma
vle32.v v8, (a0)
sub a2, a2, t0
vand.vx v16, v8, t2
sh2add a0, t0, a0
vand.vx v8, v8, t1
vsrl.vi v24, v16, 16
vsll.vi v16, v16, 16
vor.vv v8, v8, v24
vor.vv v8, v16, v8
vse32.v v8, (a1)
sh2add a1, t0, a1
bnez a2, 2b
sws/rgb2rgb: RISC-V V shuffle_bytes_xxxx functions
2022-09-28 15:29:59 +00:00
ret
endfunc
func ff_shuffle_bytes_1230_rvv, zve32x
swscale/rgb2rgb2: rework RISC-V V shuffle_bytes_{1230,3012} This avoids strided loads. Before: shuffle_bytes_1230_rvv_i32: 308.7 shuffle_bytes_3012_rvv_i32: 308.7 After: shuffle_bytes_1230_rvv_i32: 46.7 shuffle_bytes_3012_rvv_i32: 46.7
2023-07-18 17:25:13 +00:00
li t1, 24
li t2, 8
j 3f
sws/rgb2rgb: RISC-V V shuffle_bytes_xxxx functions
2022-09-28 15:29:59 +00:00
endfunc
func ff_shuffle_bytes_3012_rvv, zve32x
swscale/rgb2rgb2: rework RISC-V V shuffle_bytes_{1230,3012} This avoids strided loads. Before: shuffle_bytes_1230_rvv_i32: 308.7 shuffle_bytes_3012_rvv_i32: 308.7 After: shuffle_bytes_1230_rvv_i32: 46.7 shuffle_bytes_3012_rvv_i32: 46.7
2023-07-18 17:25:13 +00:00
li t1, 8
li t2, 24
3:
srai a2, a2, 2
4:
vsetvli t0, a2, e32, m8, ta, ma
vle32.v v8, (a0)
sub a2, a2, t0
vsll.vx v16, v8, t1
sh2add a0, t0, a0
vsrl.vx v8, v8, t2
vor.vv v16, v16, v8
vse32.v v16, (a1)
sh2add a1, t0, a1
bnez a2, 4b
ret
sws/rgb2rgb: RISC-V V shuffle_bytes_xxxx functions
2022-09-28 15:29:59 +00:00
endfunc
sws/rgb2rgb: RISC-V V interleaveBytes
2022-09-28 15:30:00 +00:00
func ff_interleave_bytes_rvv, zve32x
1:
mv t0, a0
mv t1, a1
mv t2, a2
mv t3, a3
addi a4, a4, -1
2:
swscale/rgb2rgb: unroll R-V V interleave_bytes
2023-09-30 09:03:37 +00:00
vsetvli t4, t3, e8, m4, ta, ma
sws/rgb2rgb: RISC-V V interleaveBytes
2022-09-28 15:30:00 +00:00
sub t3, t3, t4
vle8.v v8, (t0)
add t0, t4, t0
swscale/rgb2rgb: unroll R-V V interleave_bytes
2023-09-30 09:03:37 +00:00
vle8.v v12, (t1)
sws/rgb2rgb: RISC-V V interleaveBytes
2022-09-28 15:30:00 +00:00
add t1, t4, t1
vsseg2e8.v v8, (t2)
sh1add t2, t4, t2
swscale/rgb2rgb: fix extra iteration in R-V V interleave There was an additional iteration doing nothing for each line, due to checking the selected vector length instead of the available vector length.
2023-10-01 17:57:05 +00:00
bnez t3, 2b
sws/rgb2rgb: RISC-V V interleaveBytes
2022-09-28 15:30:00 +00:00
add a0, a0, a5
add a1, a1, a6
add a2, a2, a7
bnez a4, 1b
ret
endfunc
sws/rgb2rgb: RISC-V 64-bit V packed YUYV/UYVY to planar 4:2:2 This is currently 64-bit only because the stack spilling code would not assemble on RV32I (and it would corrupt s0 and s1 on RV128I, in theory). This could be added later in the unlikely that someone wants it.
2022-09-28 15:30:01 +00:00
swscale/rgb2rgb: R-V V deinterleaveBytes
2023-10-01 17:59:50 +00:00
func ff_deinterleave_bytes_rvv, zve32x
1:
mv t0, a0
mv t1, a1
mv t2, a2
mv t3, a3
addi a4, a4, -1
2:
vsetvli t4, t3, e8, m4, ta, ma
sub t3, t3, t4
vlseg2e8.v v8, (t0)
sh1add t0, t4, t0
vse8.v v8, (t1)
add t1, t4, t1
vse8.v v12, (t2)
add t2, t4, t2
bnez t3, 2b
add a0, a0, a5
add a1, a1, a6
add a2, a2, a7
bnez a4, 1b
ret
endfunc
sws/rgb2rgb: fix unaligned accesses in R-V V YUYV to I422p In my personal opinion, we should not need to support unaligned YUY2 pixel maps. They should always be aligned to at least 32 bits, and the current code assumes just 16 bits. However checkasm does test for unaligned input bitmaps. QEMU accepts it, but real hardware dose not. In this particular case, we can at the same time improve performance and handle unaligned inputs, so do just that. uyvytoyuv422_c: 104379.0 uyvytoyuv422_c: 104060.0 uyvytoyuv422_rvv_i32: 25284.0 (before) uyvytoyuv422_rvv_i32: 19303.2 (after)
2023-11-09 18:19:47 +00:00
.macro yuy2_to_i422p luma, chroma
srai t4, a4, 1 // pixel width -> chroma width
swscale/rgb2rgb: avoid S-regs in RISC-V V uyvytoyuv422 We can make do with callee-clobbered registers only now. As an added bonus, this makes the code XLEN-independent.
2023-09-29 19:36:16 +00:00
lw t6, (sp)
sws/rgb2rgb: fix unaligned accesses in R-V V YUYV to I422p In my personal opinion, we should not need to support unaligned YUY2 pixel maps. They should always be aligned to at least 32 bits, and the current code assumes just 16 bits. However checkasm does test for unaligned input bitmaps. QEMU accepts it, but real hardware dose not. In this particular case, we can at the same time improve performance and handle unaligned inputs, so do just that. uyvytoyuv422_c: 104379.0 uyvytoyuv422_c: 104060.0 uyvytoyuv422_rvv_i32: 25284.0 (before) uyvytoyuv422_rvv_i32: 19303.2 (after)
2023-11-09 18:19:47 +00:00
slli t5, a4, 1 // pixel width -> (source) byte width
sws/rgb2rgb: rework R-V V YUY2 to 4:2:2 planar This saves three scratch registers and three instructions per line. The performance gains are mostly negligible. The main point is to free up registers for further rework.
2023-11-09 17:54:39 +00:00
sub a6, a6, a4
sws/rgb2rgb: fix unaligned accesses in R-V V YUYV to I422p In my personal opinion, we should not need to support unaligned YUY2 pixel maps. They should always be aligned to at least 32 bits, and the current code assumes just 16 bits. However checkasm does test for unaligned input bitmaps. QEMU accepts it, but real hardware dose not. In this particular case, we can at the same time improve performance and handle unaligned inputs, so do just that. uyvytoyuv422_c: 104379.0 uyvytoyuv422_c: 104060.0 uyvytoyuv422_rvv_i32: 25284.0 (before) uyvytoyuv422_rvv_i32: 19303.2 (after)
2023-11-09 18:19:47 +00:00
sub a7, a7, t4
sub t6, t6, t5
vsetvli t2, zero, e8, m4, ta, ma
sws/rgb2rgb: RISC-V 64-bit V packed YUYV/UYVY to planar 4:2:2 This is currently 64-bit only because the stack spilling code would not assemble on RV32I (and it would corrupt s0 and s1 on RV128I, in theory). This could be added later in the unlikely that someone wants it.
2022-09-28 15:30:01 +00:00
1:
mv t4, a4
addi a5, a5, -1
2:
sws/rgb2rgb: fix unaligned accesses in R-V V YUYV to I422p In my personal opinion, we should not need to support unaligned YUY2 pixel maps. They should always be aligned to at least 32 bits, and the current code assumes just 16 bits. However checkasm does test for unaligned input bitmaps. QEMU accepts it, but real hardware dose not. In this particular case, we can at the same time improve performance and handle unaligned inputs, so do just that. uyvytoyuv422_c: 104379.0 uyvytoyuv422_c: 104060.0 uyvytoyuv422_rvv_i32: 25284.0 (before) uyvytoyuv422_rvv_i32: 19303.2 (after)
2023-11-09 18:19:47 +00:00
min t0, t2, t4 // ensure even VL on penultimate iteration
vsetvli t0, t0, e8, m4, ta, ma
vlseg2e8.v v16, (a3)
srli t1, t0, 1
vsetvli zero, t1, e8, m2, ta, ma
vnsrl.wi v24, \chroma, 0 // U
sub t4, t4, t0
vnsrl.wi v28, \chroma, 8 // V
sh1add a3, t0, a3
vse8.v v24, (a1)
add a1, t1, a1
vse8.v v28, (a2)
add a2, t1, a2
vsetvli zero, t0, e8, m4, ta, ma
vse8.v \luma, (a0)
add a0, t0, a0
bnez t4, 2b
sws/rgb2rgb: RISC-V 64-bit V packed YUYV/UYVY to planar 4:2:2 This is currently 64-bit only because the stack spilling code would not assemble on RV32I (and it would corrupt s0 and s1 on RV128I, in theory). This could be added later in the unlikely that someone wants it.
2022-09-28 15:30:01 +00:00
swscale/rgb2rgb: avoid S-regs in RISC-V V uyvytoyuv422 We can make do with callee-clobbered registers only now. As an added bonus, this makes the code XLEN-independent.
2023-09-29 19:36:16 +00:00
add a3, a3, t6
sws/rgb2rgb: RISC-V 64-bit V packed YUYV/UYVY to planar 4:2:2 This is currently 64-bit only because the stack spilling code would not assemble on RV32I (and it would corrupt s0 and s1 on RV128I, in theory). This could be added later in the unlikely that someone wants it.
2022-09-28 15:30:01 +00:00
add a0, a0, a6
add a1, a1, a7
add a2, a2, a7
bnez a5, 1b
ret
.endm
func ff_uyvytoyuv422_rvv, zve32x
sws/rgb2rgb: fix unaligned accesses in R-V V YUYV to I422p In my personal opinion, we should not need to support unaligned YUY2 pixel maps. They should always be aligned to at least 32 bits, and the current code assumes just 16 bits. However checkasm does test for unaligned input bitmaps. QEMU accepts it, but real hardware dose not. In this particular case, we can at the same time improve performance and handle unaligned inputs, so do just that. uyvytoyuv422_c: 104379.0 uyvytoyuv422_c: 104060.0 uyvytoyuv422_rvv_i32: 25284.0 (before) uyvytoyuv422_rvv_i32: 19303.2 (after)
2023-11-09 18:19:47 +00:00
yuy2_to_i422p v20, v16
sws/rgb2rgb: RISC-V 64-bit V packed YUYV/UYVY to planar 4:2:2 This is currently 64-bit only because the stack spilling code would not assemble on RV32I (and it would corrupt s0 and s1 on RV128I, in theory). This could be added later in the unlikely that someone wants it.
2022-09-28 15:30:01 +00:00
endfunc
func ff_yuyvtoyuv422_rvv, zve32x
sws/rgb2rgb: fix unaligned accesses in R-V V YUYV to I422p In my personal opinion, we should not need to support unaligned YUY2 pixel maps. They should always be aligned to at least 32 bits, and the current code assumes just 16 bits. However checkasm does test for unaligned input bitmaps. QEMU accepts it, but real hardware dose not. In this particular case, we can at the same time improve performance and handle unaligned inputs, so do just that. uyvytoyuv422_c: 104379.0 uyvytoyuv422_c: 104060.0 uyvytoyuv422_rvv_i32: 25284.0 (before) uyvytoyuv422_rvv_i32: 19303.2 (after)
2023-11-09 18:19:47 +00:00
yuy2_to_i422p v16, v20
sws/rgb2rgb: RISC-V 64-bit V packed YUYV/UYVY to planar 4:2:2 This is currently 64-bit only because the stack spilling code would not assemble on RV32I (and it would corrupt s0 and s1 on RV128I, in theory). This could be added later in the unlikely that someone wants it.
2022-09-28 15:30:01 +00:00
endfunc