ffmpeg/FFmpeg
1
0
Fork 0
mirror of https://git.ffmpeg.org/ffmpeg.git synced 2024-10-19 04:53:25 +00:00
Code Issues Packages Projects Releases Wiki Activity
1709f3830e
FFmpeg/libavcodec/riscv/h264dsp_init.c

183 lines
7.8 KiB
C
Raw Normal View History

lavc/startcode: add R-V Zbb startcode_find_candidate The main loop processes 8 bytes in 5 instructions. For comparison, the optimal plain strnlen() requires 4 instructions per byte (6.4x worse): LBU; ADDI; BEQZ; BNE. The current libavcodec C code involves 5 instructions per byte (8x worse). Actual benchmarks may be slightly less favourable due to latency from ORC.B to BNE.
2024-05-16 14:13:22 +00:00
/*
avcodec/riscv: add h264 dc idct rvv checkasm: bench runs 131072 (1 << 17) h264_idct4_add_dc_8bpp_c: 1.5 h264_idct4_add_dc_8bpp_rvv_i64: 0.7 h264_idct4_add_dc_9bpp_c: 1.5 h264_idct4_add_dc_9bpp_rvv_i64: 0.7 h264_idct4_add_dc_10bpp_c: 1.5 h264_idct4_add_dc_10bpp_rvv_i64: 0.7 h264_idct4_add_dc_12bpp_c: 1.2 h264_idct4_add_dc_12bpp_rvv_i64: 0.7 h264_idct4_add_dc_14bpp_c: 1.2 h264_idct4_add_dc_14bpp_rvv_i64: 0.7 h264_idct8_add_dc_8bpp_c: 5.2 h264_idct8_add_dc_8bpp_rvv_i64: 1.5 h264_idct8_add_dc_9bpp_c: 5.5 h264_idct8_add_dc_9bpp_rvv_i64: 1.2 h264_idct8_add_dc_10bpp_c: 5.5 h264_idct8_add_dc_10bpp_rvv_i64: 1.2 h264_idct8_add_dc_12bpp_c: 4.2 h264_idct8_add_dc_12bpp_rvv_i64: 1.2 h264_idct8_add_dc_14bpp_c: 4.2 h264_idct8_add_dc_14bpp_rvv_i64: 1.2 Signed-off-by: J. Dekker <jdek@itanimul.li>
2024-06-10 10:43:44 +00:00
* Copyright (c) 2024 J. Dekker <jdek@itanimul.li>
lavc/startcode: add R-V Zbb startcode_find_candidate The main loop processes 8 bytes in 5 instructions. For comparison, the optimal plain strnlen() requires 4 instructions per byte (6.4x worse): LBU; ADDI; BEQZ; BNE. The current libavcodec C code involves 5 instructions per byte (8x worse). Actual benchmarks may be slightly less favourable due to latency from ORC.B to BNE.
2024-05-16 14:13:22 +00:00
* Copyright © 2024 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 "config.h"
#include <stdint.h>
lavc/h264dsp: R-V V 8-bit h264_weight_pixels There are two implementations here: - a generic scalable one processing two columns at a time, - a specialised processing one (fixed-size) row at a time. Unsurprisingly, the generic one works out better with smaller widths. With larger widths, the gains from filling vectors are outweighed by the extra cost of strided loads and stores. In other words, memory accesses become the bottleneck. T-Head C908: h264_weight2_8_c: 54.5 h264_weight2_8_rvv_i32: 13.7 h264_weight4_8_c: 101.7 h264_weight4_8_rvv_i32: 27.5 h264_weight8_8_c: 197.0 h264_weight8_8_rvv_i32: 75.5 h264_weight16_8_c: 385.0 h264_weight16_8_rvv_i32: 74.2 SpacemiT X60: h264_weight2_8_c: 48.5 h264_weight2_8_rvv_i32: 8.2 h264_weight4_8_c: 90.7 h264_weight4_8_rvv_i32: 16.5 h264_weight8_8_c: 175.0 h264_weight8_8_rvv_i32: 37.7 h264_weight16_8_c: 342.2 h264_weight16_8_rvv_i32: 66.0
2024-07-04 18:38:48 +00:00
#include <string.h>
lavc/startcode: add R-V Zbb startcode_find_candidate The main loop processes 8 bytes in 5 instructions. For comparison, the optimal plain strnlen() requires 4 instructions per byte (6.4x worse): LBU; ADDI; BEQZ; BNE. The current libavcodec C code involves 5 instructions per byte (8x worse). Actual benchmarks may be slightly less favourable due to latency from ORC.B to BNE.
2024-05-16 14:13:22 +00:00
#include "libavutil/attributes.h"
#include "libavutil/cpu.h"
lavc/h264dsp: R-V V 8-bit luma loop filter T-Head C908 (cycles): h264_h_loop_filter_luma_8bpp_c: 297.5 h264_h_loop_filter_luma_8bpp_rvv_i32: 369.2 h264_v_loop_filter_luma_8bpp_c: 862.7 h264_v_loop_filter_luma_8bpp_rvv_i32: 199.7 Performance in the horizontal scenario seems worse than scalar. x86 SSE2 and AVX optimisations are similarly affected. This is presumably caused by unlucky inputs from checkasm, such that the C code short-circuits almost all filter calculations.
2024-06-28 18:56:12 +00:00
#include "libavutil/riscv/cpu.h"
lavc/startcode: add R-V Zbb startcode_find_candidate The main loop processes 8 bytes in 5 instructions. For comparison, the optimal plain strnlen() requires 4 instructions per byte (6.4x worse): LBU; ADDI; BEQZ; BNE. The current libavcodec C code involves 5 instructions per byte (8x worse). Actual benchmarks may be slightly less favourable due to latency from ORC.B to BNE.
2024-05-16 14:13:22 +00:00
#include "libavcodec/h264dsp.h"
lavc/h264dsp: R-V V 8-bit h264_biweight_pixels T-Head C908: h264_biweight2_8_c: 58.0 h264_biweight2_8_rvv_i32: 11.2 h264_biweight4_8_c: 106.0 h264_biweight4_8_rvv_i32: 22.7 h264_biweight8_8_c: 205.7 h264_biweight8_8_rvv_i32: 50.0 h264_biweight16_8_c: 403.5 h264_biweight16_8_rvv_i32: 83.2 SpacemiT X60: h264_weight2_8_c: 48.2 h264_weight2_8_rvv_i32: 8.2 h264_weight4_8_c: 90.5 h264_weight4_8_rvv_i32: 16.5 h264_weight8_8_c: 175.2 h264_weight8_8_rvv_i32: 38.0 h264_weight16_8_c: 342.2 h264_weight16_8_rvv_i32: 66.0
2024-07-05 20:03:28 +00:00
extern const struct {
const h264_weight_func weight;
const h264_biweight_func biweight;
} ff_h264_weight_funcs_8_rvv[];
lavc/h264dsp: R-V V 8-bit h264_weight_pixels There are two implementations here: - a generic scalable one processing two columns at a time, - a specialised processing one (fixed-size) row at a time. Unsurprisingly, the generic one works out better with smaller widths. With larger widths, the gains from filling vectors are outweighed by the extra cost of strided loads and stores. In other words, memory accesses become the bottleneck. T-Head C908: h264_weight2_8_c: 54.5 h264_weight2_8_rvv_i32: 13.7 h264_weight4_8_c: 101.7 h264_weight4_8_rvv_i32: 27.5 h264_weight8_8_c: 197.0 h264_weight8_8_rvv_i32: 75.5 h264_weight16_8_c: 385.0 h264_weight16_8_rvv_i32: 74.2 SpacemiT X60: h264_weight2_8_c: 48.5 h264_weight2_8_rvv_i32: 8.2 h264_weight4_8_c: 90.7 h264_weight4_8_rvv_i32: 16.5 h264_weight8_8_c: 175.0 h264_weight8_8_rvv_i32: 37.7 h264_weight16_8_c: 342.2 h264_weight16_8_rvv_i32: 66.0
2024-07-04 18:38:48 +00:00
lavc/h264dsp: R-V V 8-bit luma loop filter T-Head C908 (cycles): h264_h_loop_filter_luma_8bpp_c: 297.5 h264_h_loop_filter_luma_8bpp_rvv_i32: 369.2 h264_v_loop_filter_luma_8bpp_c: 862.7 h264_v_loop_filter_luma_8bpp_rvv_i32: 199.7 Performance in the horizontal scenario seems worse than scalar. x86 SSE2 and AVX optimisations are similarly affected. This is presumably caused by unlucky inputs from checkasm, such that the C code short-circuits almost all filter calculations.
2024-06-28 18:56:12 +00:00
void ff_h264_v_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride,
int alpha, int beta, int8_t *tc0);
void ff_h264_h_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride,
int alpha, int beta, int8_t *tc0);
lavc/h264dsp: R-V V 8-bit MBAFF loop filter Performance is (unfortunately) the same as with non-MBAFF, since the hardware under test does not short-circuit vector tail calculations. (IMO, a generic solution or work-around should be agreed on, rather than bespoke approaches all over the place.)
2024-06-30 08:24:43 +00:00
void ff_h264_h_loop_filter_luma_mbaff_8_rvv(uint8_t *pix, ptrdiff_t stride,
int alpha, int beta, int8_t *tc0);
lavc/h264dsp: R-V V loop_filter_chroma T-Head C908: h264_v_loop_filter_chroma_8bpp_c: 137.4 h264_v_loop_filter_chroma_8bpp_rvv_i32: 54.2
2024-08-20 18:59:00 +00:00
void ff_h264_v_loop_filter_chroma_8_rvv(uint8_t *pix, ptrdiff_t stride,
int alpha, int beta, int8_t *tc0);
void ff_h264_h_loop_filter_chroma_8_rvv(uint8_t *pix, ptrdiff_t stride,
int alpha, int beta, int8_t *tc0);
void ff_h264_h_loop_filter_chroma_mbaff_8_rvv(uint8_t *pix, ptrdiff_t stride,
int alpha, int beta,
int8_t *tc0);
lavc/h264dsp: R-V V 8-bit luma loop filter T-Head C908 (cycles): h264_h_loop_filter_luma_8bpp_c: 297.5 h264_h_loop_filter_luma_8bpp_rvv_i32: 369.2 h264_v_loop_filter_luma_8bpp_c: 862.7 h264_v_loop_filter_luma_8bpp_rvv_i32: 199.7 Performance in the horizontal scenario seems worse than scalar. x86 SSE2 and AVX optimisations are similarly affected. This is presumably caused by unlucky inputs from checkasm, such that the C code short-circuits almost all filter calculations.
2024-06-28 18:56:12 +00:00
lavc/h264dsp: R-V V high-depth idct_add{,intra}16, idct8_add4 As with 8-bit, this tends to be faster, but results are all over the place due to the variable distribution of non-zero coefficients.
2024-07-15 18:19:39 +00:00
#define IDCT_DEPTH(depth) \
void ff_h264_idct_add_##depth##_rvv(uint8_t *d, int16_t *s, int stride); \
void ff_h264_idct8_add_##depth##_rvv(uint8_t *d, int16_t *s, int stride); \
void ff_h264_idct4_dc_add_##depth##_rvv(uint8_t *, int16_t *, int); \
void ff_h264_idct8_dc_add_##depth##_rvv(uint8_t *, int16_t *, int); \
void ff_h264_idct_add16_##depth##_rvv(uint8_t *d, const int *soffset, \
int16_t *s, int stride, \
const uint8_t nnzc[5 * 8]); \
void ff_h264_idct_add16intra_##depth##_rvv(uint8_t *d, const int *soffset, \
int16_t *s, int stride, \
const uint8_t nnzc[5 * 8]); \
void ff_h264_idct8_add4_##depth##_rvv(uint8_t *d, const int *soffset, \
int16_t *s, int stride, \
lavc/h264dsp: R-V V idct4_add8 (all depths) These are really just wrappers for idct4_add16intra functions, which are in turn mostly wrappers for idct4_add and idct4_dc_add functions. For benchmarks refer to the later two sets.
2024-07-31 19:04:45 +00:00
const uint8_t nnzc[5 * 8]); \
void ff_h264_idct4_add8_##depth##_rvv(uint8_t **d, const int *soffset, \
int16_t *s, int stride, \
const uint8_t nnzc[5 * 8]); \
void ff_h264_idct4_add8_422_##depth##_rvv(uint8_t **d, const int *soffset, \
int16_t *s, int stride, \
const uint8_t nnzc[5 * 8]);
lavc/h264dsp: R-V V high-depth idct_add{,intra}16, idct8_add4 As with 8-bit, this tends to be faster, but results are all over the place due to the variable distribution of non-zero coefficients.
2024-07-15 18:19:39 +00:00
IDCT_DEPTH(8)
IDCT_DEPTH(9)
IDCT_DEPTH(10)
IDCT_DEPTH(12)
IDCT_DEPTH(14)
#undef IDCT_DEPTH
lavc/h264dsp: R-V V high-depth h264_idct_add T-Head C908 (cycles): h264_idct4_add_9bpp_c: 248.2 h264_idct4_add_9bpp_rvv_i32: 128.7 h264_idct4_add_10bpp_c: 256.7 h264_idct4_add_10bpp_rvv_i32: 128.7 h264_idct4_add_12bpp_c: 252.5 h264_idct4_add_12bpp_rvv_i32: 129.7 h264_idct4_add_14bpp_c: 258.0 h264_idct4_add_14bpp_rvv_i32: 129.7
2024-07-02 19:03:07 +00:00
lavc/h264dsp: R-V V add_pixels4 and 8-bit add_pixels8 T-Head C908 (cycles): h264_add_pixels4_8bpp_c: 93.5 h264_add_pixels4_8bpp_rvv_i32: 39.5 h264_add_pixels4_9bpp_c: 87.5 h264_add_pixels4_9bpp_rvv_i64: 50.5 h264_add_pixels4_10bpp_c: 87.5 h264_add_pixels4_10bpp_rvv_i64: 50.5 h264_add_pixels4_12bpp_c: 87.5 h264_add_pixels4_12bpp_rvv_i64: 50.5 h264_add_pixels4_14bpp_c: 87.5 h264_add_pixels4_14bpp_rvv_i64: 50.5 h264_add_pixels8_8bpp_c: 265.2 h264_add_pixels8_8bpp_rvv_i64: 84.5
2024-07-13 12:43:27 +00:00
void ff_h264_add_pixels8_8_rvv(uint8_t *dst, int16_t *block, int stride);
void ff_h264_add_pixels4_8_rvv(uint8_t *dst, int16_t *block, int stride);
lavc/h264dsp: R-V V high-depth add_pixels8 T-Head C908 (cycles); h264_add_pixels8_9bpp_c: 270.5 h264_add_pixels8_9bpp_rvv_i32: 164.2 h264_add_pixels8_10bpp_c: 270.5 h264_add_pixels8_10bpp_rvv_i32: 164.2 h264_add_pixels8_12bpp_c: 270.5 h264_add_pixels8_12bpp_rvv_i32: 164.2 h264_add_pixels8_14bpp_c: 270.5 h264_add_pixels8_14bpp_rvv_i32: 164.2
2024-07-13 13:01:14 +00:00
void ff_h264_add_pixels8_16_rvv(uint8_t *dst, int16_t *block, int stride);
lavc/h264dsp: R-V V add_pixels4 and 8-bit add_pixels8 T-Head C908 (cycles): h264_add_pixels4_8bpp_c: 93.5 h264_add_pixels4_8bpp_rvv_i32: 39.5 h264_add_pixels4_9bpp_c: 87.5 h264_add_pixels4_9bpp_rvv_i64: 50.5 h264_add_pixels4_10bpp_c: 87.5 h264_add_pixels4_10bpp_rvv_i64: 50.5 h264_add_pixels4_12bpp_c: 87.5 h264_add_pixels4_12bpp_rvv_i64: 50.5 h264_add_pixels4_14bpp_c: 87.5 h264_add_pixels4_14bpp_rvv_i64: 50.5 h264_add_pixels8_8bpp_c: 265.2 h264_add_pixels8_8bpp_rvv_i64: 84.5
2024-07-13 12:43:27 +00:00
void ff_h264_add_pixels4_16_rvv(uint8_t *dst, int16_t *block, int stride);
lavc/startcode: add R-V Zbb startcode_find_candidate The main loop processes 8 bytes in 5 instructions. For comparison, the optimal plain strnlen() requires 4 instructions per byte (6.4x worse): LBU; ADDI; BEQZ; BNE. The current libavcodec C code involves 5 instructions per byte (8x worse). Actual benchmarks may be slightly less favourable due to latency from ORC.B to BNE.
2024-05-16 14:13:22 +00:00
extern int ff_startcode_find_candidate_rvb(const uint8_t *, int);
lavc/startcode: add R-V V startcode_find_candidate
2024-05-12 10:54:33 +00:00
extern int ff_startcode_find_candidate_rvv(const uint8_t *, int);
lavc/startcode: add R-V Zbb startcode_find_candidate The main loop processes 8 bytes in 5 instructions. For comparison, the optimal plain strnlen() requires 4 instructions per byte (6.4x worse): LBU; ADDI; BEQZ; BNE. The current libavcodec C code involves 5 instructions per byte (8x worse). Actual benchmarks may be slightly less favourable due to latency from ORC.B to BNE.
2024-05-16 14:13:22 +00:00
av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp, const int bit_depth,
const int chroma_format_idc)
{
#if HAVE_RV
int flags = av_get_cpu_flags();
if (flags & AV_CPU_FLAG_RVB_BASIC)
dsp->startcode_find_candidate = ff_startcode_find_candidate_rvb;
lavc/startcode: add R-V V startcode_find_candidate
2024-05-12 10:54:33 +00:00
# if HAVE_RVV
lavc/h264dsp: R-V V 8-bit luma loop filter T-Head C908 (cycles): h264_h_loop_filter_luma_8bpp_c: 297.5 h264_h_loop_filter_luma_8bpp_rvv_i32: 369.2 h264_v_loop_filter_luma_8bpp_c: 862.7 h264_v_loop_filter_luma_8bpp_rvv_i32: 199.7 Performance in the horizontal scenario seems worse than scalar. x86 SSE2 and AVX optimisations are similarly affected. This is presumably caused by unlucky inputs from checkasm, such that the C code short-circuits almost all filter calculations.
2024-06-28 18:56:12 +00:00
if (flags & AV_CPU_FLAG_RVV_I32) {
lavc/h264dsp: R-V V high-depth h264_idct_add T-Head C908 (cycles): h264_idct4_add_9bpp_c: 248.2 h264_idct4_add_9bpp_rvv_i32: 128.7 h264_idct4_add_10bpp_c: 256.7 h264_idct4_add_10bpp_rvv_i32: 128.7 h264_idct4_add_12bpp_c: 252.5 h264_idct4_add_12bpp_rvv_i32: 129.7 h264_idct4_add_14bpp_c: 258.0 h264_idct4_add_14bpp_rvv_i32: 129.7
2024-07-02 19:03:07 +00:00
const bool zvl128b = ff_rv_vlen_least(128);
if (bit_depth == 8 && zvl128b) {
lavc/h264dsp: R-V V 8-bit h264_biweight_pixels T-Head C908: h264_biweight2_8_c: 58.0 h264_biweight2_8_rvv_i32: 11.2 h264_biweight4_8_c: 106.0 h264_biweight4_8_rvv_i32: 22.7 h264_biweight8_8_c: 205.7 h264_biweight8_8_rvv_i32: 50.0 h264_biweight16_8_c: 403.5 h264_biweight16_8_rvv_i32: 83.2 SpacemiT X60: h264_weight2_8_c: 48.2 h264_weight2_8_rvv_i32: 8.2 h264_weight4_8_c: 90.5 h264_weight4_8_rvv_i32: 16.5 h264_weight8_8_c: 175.2 h264_weight8_8_rvv_i32: 38.0 h264_weight16_8_c: 342.2 h264_weight16_8_rvv_i32: 66.0
2024-07-05 20:03:28 +00:00
for (int i = 0; i < 4; i++) {
dsp->weight_h264_pixels_tab[i] =
ff_h264_weight_funcs_8_rvv[i].weight;
dsp->biweight_h264_pixels_tab[i] =
ff_h264_weight_funcs_8_rvv[i].biweight;
}
lavc/h264dsp: R-V V 8-bit h264_weight_pixels There are two implementations here: - a generic scalable one processing two columns at a time, - a specialised processing one (fixed-size) row at a time. Unsurprisingly, the generic one works out better with smaller widths. With larger widths, the gains from filling vectors are outweighed by the extra cost of strided loads and stores. In other words, memory accesses become the bottleneck. T-Head C908: h264_weight2_8_c: 54.5 h264_weight2_8_rvv_i32: 13.7 h264_weight4_8_c: 101.7 h264_weight4_8_rvv_i32: 27.5 h264_weight8_8_c: 197.0 h264_weight8_8_rvv_i32: 75.5 h264_weight16_8_c: 385.0 h264_weight16_8_rvv_i32: 74.2 SpacemiT X60: h264_weight2_8_c: 48.5 h264_weight2_8_rvv_i32: 8.2 h264_weight4_8_c: 90.7 h264_weight4_8_rvv_i32: 16.5 h264_weight8_8_c: 175.0 h264_weight8_8_rvv_i32: 37.7 h264_weight16_8_c: 342.2 h264_weight16_8_rvv_i32: 66.0
2024-07-04 18:38:48 +00:00
lavc/h264dsp: R-V V 8-bit luma loop filter T-Head C908 (cycles): h264_h_loop_filter_luma_8bpp_c: 297.5 h264_h_loop_filter_luma_8bpp_rvv_i32: 369.2 h264_v_loop_filter_luma_8bpp_c: 862.7 h264_v_loop_filter_luma_8bpp_rvv_i32: 199.7 Performance in the horizontal scenario seems worse than scalar. x86 SSE2 and AVX optimisations are similarly affected. This is presumably caused by unlucky inputs from checkasm, such that the C code short-circuits almost all filter calculations.
2024-06-28 18:56:12 +00:00
dsp->h264_v_loop_filter_luma = ff_h264_v_loop_filter_luma_8_rvv;
dsp->h264_h_loop_filter_luma = ff_h264_h_loop_filter_luma_8_rvv;
lavc/h264dsp: R-V V 8-bit MBAFF loop filter Performance is (unfortunately) the same as with non-MBAFF, since the hardware under test does not short-circuit vector tail calculations. (IMO, a generic solution or work-around should be agreed on, rather than bespoke approaches all over the place.)
2024-06-30 08:24:43 +00:00
dsp->h264_h_loop_filter_luma_mbaff =
ff_h264_h_loop_filter_luma_mbaff_8_rvv;
lavc/h264dsp: R-V V loop_filter_chroma T-Head C908: h264_v_loop_filter_chroma_8bpp_c: 137.4 h264_v_loop_filter_chroma_8bpp_rvv_i32: 54.2
2024-08-20 18:59:00 +00:00
dsp->h264_v_loop_filter_chroma =
ff_h264_v_loop_filter_chroma_8_rvv;
if (chroma_format_idc <= 1) {
dsp->h264_h_loop_filter_chroma =
ff_h264_h_loop_filter_chroma_8_rvv;
dsp->h264_h_loop_filter_chroma_mbaff =
ff_h264_h_loop_filter_chroma_mbaff_8_rvv;
}
lavc/h264dsp: R-V V 8-bit h264_idct_add16 While this *tends* to be faster than plain C, the performance numbers are all over the place, presuambly due to the conditional character of the main loop. Some additional micro-optimisations should be feasible after the underlying h264_idct_add and h264_idct_dc_add functions are also implemented. Then it will no longer be necesseray to stricly abide by the C ABI.
2024-07-01 20:41:37 +00:00
avcodec/riscv: add h264 dc idct rvv checkasm: bench runs 131072 (1 << 17) h264_idct4_add_dc_8bpp_c: 1.5 h264_idct4_add_dc_8bpp_rvv_i64: 0.7 h264_idct4_add_dc_9bpp_c: 1.5 h264_idct4_add_dc_9bpp_rvv_i64: 0.7 h264_idct4_add_dc_10bpp_c: 1.5 h264_idct4_add_dc_10bpp_rvv_i64: 0.7 h264_idct4_add_dc_12bpp_c: 1.2 h264_idct4_add_dc_12bpp_rvv_i64: 0.7 h264_idct4_add_dc_14bpp_c: 1.2 h264_idct4_add_dc_14bpp_rvv_i64: 0.7 h264_idct8_add_dc_8bpp_c: 5.2 h264_idct8_add_dc_8bpp_rvv_i64: 1.5 h264_idct8_add_dc_9bpp_c: 5.5 h264_idct8_add_dc_9bpp_rvv_i64: 1.2 h264_idct8_add_dc_10bpp_c: 5.5 h264_idct8_add_dc_10bpp_rvv_i64: 1.2 h264_idct8_add_dc_12bpp_c: 4.2 h264_idct8_add_dc_12bpp_rvv_i64: 1.2 h264_idct8_add_dc_14bpp_c: 4.2 h264_idct8_add_dc_14bpp_rvv_i64: 1.2 Signed-off-by: J. Dekker <jdek@itanimul.li>
2024-06-10 10:43:44 +00:00
dsp->h264_idct_add = ff_h264_idct_add_8_rvv;
lavc/h264dsp: R-V V 8-bit h264_idct8_add T-Head C908 (cycles): h264_idct8_add_8bpp_c: 1072.0 h264_idct8_add_8bpp_rvv_i32: 318.5
2024-07-03 16:49:54 +00:00
dsp->h264_idct8_add = ff_h264_idct8_add_8_rvv;
lavc/h264dsp: use RISC-V B extension This saves one register and one instruction per transform. add16 and add16intra thus become stack-less.
2024-07-19 19:16:01 +00:00
if (flags & AV_CPU_FLAG_RVB) {
lavc/h264dsp: use saturing add/sub for R-V V 8-bit DC add T-Head C908 (cycles): h264_idct4_dc_add_8bpp_c: 109.2 h264_idct4_dc_add_8bpp_rvv_i32: 34.5 (before) h264_idct4_dc_add_8bpp_rvv_i32: 25.5 (after) h264_idct8_dc_add_8bpp_c: 418.7 h264_idct8_dc_add_8bpp_rvv_i64: 69.5 (before) h264_idct8_dc_add_8bpp_rvv_i64: 33.5 (after)
2024-07-25 17:47:34 +00:00
dsp->h264_idct_dc_add = ff_h264_idct4_dc_add_8_rvv;
lavc/h264dsp: use RISC-V B extension This saves one register and one instruction per transform. add16 and add16intra thus become stack-less.
2024-07-19 19:16:01 +00:00
dsp->h264_idct_add16 = ff_h264_idct_add16_8_rvv;
dsp->h264_idct_add16intra = ff_h264_idct_add16intra_8_rvv;
lavc/h264dsp: R-V V 8-bit h264_idct_add16 While this *tends* to be faster than plain C, the performance numbers are all over the place, presuambly due to the conditional character of the main loop. Some additional micro-optimisations should be feasible after the underlying h264_idct_add and h264_idct_dc_add functions are also implemented. Then it will no longer be necesseray to stricly abide by the C ABI.
2024-07-01 20:41:37 +00:00
# if __riscv_xlen == 64
lavc/h264dsp: use RISC-V B extension This saves one register and one instruction per transform. add16 and add16intra thus become stack-less.
2024-07-19 19:16:01 +00:00
dsp->h264_idct8_add4 = ff_h264_idct8_add4_8_rvv;
lavc/h264dsp: R-V V idct4_add8 (all depths) These are really just wrappers for idct4_add16intra functions, which are in turn mostly wrappers for idct4_add and idct4_dc_add functions. For benchmarks refer to the later two sets.
2024-07-31 19:04:45 +00:00
if (chroma_format_idc <= 1)
dsp->h264_idct_add8 = ff_h264_idct4_add8_8_rvv;
else
dsp->h264_idct_add8 = ff_h264_idct4_add8_422_8_rvv;
lavc/h264dsp: R-V V 8-bit h264_idct_add16 While this *tends* to be faster than plain C, the performance numbers are all over the place, presuambly due to the conditional character of the main loop. Some additional micro-optimisations should be feasible after the underlying h264_idct_add and h264_idct_dc_add functions are also implemented. Then it will no longer be necesseray to stricly abide by the C ABI.
2024-07-01 20:41:37 +00:00
# endif
lavc/h264dsp: use RISC-V B extension This saves one register and one instruction per transform. add16 and add16intra thus become stack-less.
2024-07-19 19:16:01 +00:00
}
avcodec/riscv: add h264 dc idct rvv checkasm: bench runs 131072 (1 << 17) h264_idct4_add_dc_8bpp_c: 1.5 h264_idct4_add_dc_8bpp_rvv_i64: 0.7 h264_idct4_add_dc_9bpp_c: 1.5 h264_idct4_add_dc_9bpp_rvv_i64: 0.7 h264_idct4_add_dc_10bpp_c: 1.5 h264_idct4_add_dc_10bpp_rvv_i64: 0.7 h264_idct4_add_dc_12bpp_c: 1.2 h264_idct4_add_dc_12bpp_rvv_i64: 0.7 h264_idct4_add_dc_14bpp_c: 1.2 h264_idct4_add_dc_14bpp_rvv_i64: 0.7 h264_idct8_add_dc_8bpp_c: 5.2 h264_idct8_add_dc_8bpp_rvv_i64: 1.5 h264_idct8_add_dc_9bpp_c: 5.5 h264_idct8_add_dc_9bpp_rvv_i64: 1.2 h264_idct8_add_dc_10bpp_c: 5.5 h264_idct8_add_dc_10bpp_rvv_i64: 1.2 h264_idct8_add_dc_12bpp_c: 4.2 h264_idct8_add_dc_12bpp_rvv_i64: 1.2 h264_idct8_add_dc_14bpp_c: 4.2 h264_idct8_add_dc_14bpp_rvv_i64: 1.2 Signed-off-by: J. Dekker <jdek@itanimul.li>
2024-06-10 10:43:44 +00:00
if (flags & AV_CPU_FLAG_RVV_I64) {
lavc/h264dsp: R-V V add_pixels4 and 8-bit add_pixels8 T-Head C908 (cycles): h264_add_pixels4_8bpp_c: 93.5 h264_add_pixels4_8bpp_rvv_i32: 39.5 h264_add_pixels4_9bpp_c: 87.5 h264_add_pixels4_9bpp_rvv_i64: 50.5 h264_add_pixels4_10bpp_c: 87.5 h264_add_pixels4_10bpp_rvv_i64: 50.5 h264_add_pixels4_12bpp_c: 87.5 h264_add_pixels4_12bpp_rvv_i64: 50.5 h264_add_pixels4_14bpp_c: 87.5 h264_add_pixels4_14bpp_rvv_i64: 50.5 h264_add_pixels8_8bpp_c: 265.2 h264_add_pixels8_8bpp_rvv_i64: 84.5
2024-07-13 12:43:27 +00:00
dsp->h264_add_pixels8_clear = ff_h264_add_pixels8_8_rvv;
lavc/h264dsp: use saturing add/sub for R-V V 8-bit DC add T-Head C908 (cycles): h264_idct4_dc_add_8bpp_c: 109.2 h264_idct4_dc_add_8bpp_rvv_i32: 34.5 (before) h264_idct4_dc_add_8bpp_rvv_i32: 25.5 (after) h264_idct8_dc_add_8bpp_c: 418.7 h264_idct8_dc_add_8bpp_rvv_i64: 69.5 (before) h264_idct8_dc_add_8bpp_rvv_i64: 33.5 (after)
2024-07-25 17:47:34 +00:00
if (flags & AV_CPU_FLAG_RVB)
dsp->h264_idct8_dc_add = ff_h264_idct8_dc_add_8_rvv;
avcodec/riscv: add h264 dc idct rvv checkasm: bench runs 131072 (1 << 17) h264_idct4_add_dc_8bpp_c: 1.5 h264_idct4_add_dc_8bpp_rvv_i64: 0.7 h264_idct4_add_dc_9bpp_c: 1.5 h264_idct4_add_dc_9bpp_rvv_i64: 0.7 h264_idct4_add_dc_10bpp_c: 1.5 h264_idct4_add_dc_10bpp_rvv_i64: 0.7 h264_idct4_add_dc_12bpp_c: 1.2 h264_idct4_add_dc_12bpp_rvv_i64: 0.7 h264_idct4_add_dc_14bpp_c: 1.2 h264_idct4_add_dc_14bpp_rvv_i64: 0.7 h264_idct8_add_dc_8bpp_c: 5.2 h264_idct8_add_dc_8bpp_rvv_i64: 1.5 h264_idct8_add_dc_9bpp_c: 5.5 h264_idct8_add_dc_9bpp_rvv_i64: 1.2 h264_idct8_add_dc_10bpp_c: 5.5 h264_idct8_add_dc_10bpp_rvv_i64: 1.2 h264_idct8_add_dc_12bpp_c: 4.2 h264_idct8_add_dc_12bpp_rvv_i64: 1.2 h264_idct8_add_dc_14bpp_c: 4.2 h264_idct8_add_dc_14bpp_rvv_i64: 1.2 Signed-off-by: J. Dekker <jdek@itanimul.li>
2024-06-10 10:43:44 +00:00
}
lavc/h264dsp: R-V V add_pixels4 and 8-bit add_pixels8 T-Head C908 (cycles): h264_add_pixels4_8bpp_c: 93.5 h264_add_pixels4_8bpp_rvv_i32: 39.5 h264_add_pixels4_9bpp_c: 87.5 h264_add_pixels4_9bpp_rvv_i64: 50.5 h264_add_pixels4_10bpp_c: 87.5 h264_add_pixels4_10bpp_rvv_i64: 50.5 h264_add_pixels4_12bpp_c: 87.5 h264_add_pixels4_12bpp_rvv_i64: 50.5 h264_add_pixels4_14bpp_c: 87.5 h264_add_pixels4_14bpp_rvv_i64: 50.5 h264_add_pixels8_8bpp_c: 265.2 h264_add_pixels8_8bpp_rvv_i64: 84.5
2024-07-13 12:43:27 +00:00
dsp->h264_add_pixels4_clear = ff_h264_add_pixels4_8_rvv;
lavc/h264dsp: R-V V 8-bit luma loop filter T-Head C908 (cycles): h264_h_loop_filter_luma_8bpp_c: 297.5 h264_h_loop_filter_luma_8bpp_rvv_i32: 369.2 h264_v_loop_filter_luma_8bpp_c: 862.7 h264_v_loop_filter_luma_8bpp_rvv_i32: 199.7 Performance in the horizontal scenario seems worse than scalar. x86 SSE2 and AVX optimisations are similarly affected. This is presumably caused by unlucky inputs from checkasm, such that the C code short-circuits almost all filter calculations.
2024-06-28 18:56:12 +00:00
}
lavc/h264dsp: R-V V high-depth idct_add{,intra}16, idct8_add4 As with 8-bit, this tends to be faster, but results are all over the place due to the variable distribution of non-zero coefficients.
2024-07-15 18:19:39 +00:00
#define IDCT_DEPTH(depth) \
if (bit_depth == depth) { \
if (zvl128b) \
dsp->h264_idct_add = ff_h264_idct_add_##depth##_rvv; \
lavc/riscv: depend on RVB and simplify accordingly There is no known (real) hardware with V and without the complete B extension. B was indeed required in the RISC-V application profile from 2022, earlier than V. There should not be any relevant hardware in the future either. In practice, different R-V Vector optimisations in FFmpeg already depend on every constituent of the B extension anyhow, so it would not work well.
2024-07-27 11:30:17 +00:00
if (flags & AV_CPU_FLAG_RVB) \
lavc/h264dsp: R-V V high-depth idct_add{,intra}16, idct8_add4 As with 8-bit, this tends to be faster, but results are all over the place due to the variable distribution of non-zero coefficients.
2024-07-15 18:19:39 +00:00
dsp->h264_idct8_add = ff_h264_idct8_add_##depth##_rvv; \
lavc/h264dsp: use RISC-V B extension This saves one register and one instruction per transform. add16 and add16intra thus become stack-less.
2024-07-19 19:16:01 +00:00
if (zvl128b && (flags & AV_CPU_FLAG_RVB)) { \
lavc/h264dsp: R-V V high-depth idct_add{,intra}16, idct8_add4 As with 8-bit, this tends to be faster, but results are all over the place due to the variable distribution of non-zero coefficients.
2024-07-15 18:19:39 +00:00
dsp->h264_idct_dc_add = ff_h264_idct4_dc_add_##depth##_rvv; \
dsp->h264_idct8_dc_add = ff_h264_idct8_dc_add_##depth##_rvv; \
lavc/h264dsp: R-V V idct4_add8 (all depths) These are really just wrappers for idct4_add16intra functions, which are in turn mostly wrappers for idct4_add and idct4_dc_add functions. For benchmarks refer to the later two sets.
2024-07-31 19:04:45 +00:00
dsp->h264_idct_add16 = ff_h264_idct_add16_##depth##_rvv; \
dsp->h264_idct_add16intra = \
ff_h264_idct_add16intra_##depth##_rvv; \
lavc/h264dsp: use RISC-V B extension This saves one register and one instruction per transform. add16 and add16intra thus become stack-less.
2024-07-19 19:16:01 +00:00
if (__riscv_xlen == 64) { \
lavc/h264dsp: R-V V idct4_add8 (all depths) These are really just wrappers for idct4_add16intra functions, which are in turn mostly wrappers for idct4_add and idct4_dc_add functions. For benchmarks refer to the later two sets.
2024-07-31 19:04:45 +00:00
if (chroma_format_idc <= 1) \
dsp->h264_idct_add8 = \
ff_h264_idct4_add8_##depth##_rvv; \
else \
dsp->h264_idct_add8 = \
ff_h264_idct4_add8_422_##depth##_rvv; \
lavc/h264dsp: use RISC-V B extension This saves one register and one instruction per transform. add16 and add16intra thus become stack-less.
2024-07-19 19:16:01 +00:00
} \
lavc/h264dsp: R-V V high-depth idct_add{,intra}16, idct8_add4 As with 8-bit, this tends to be faster, but results are all over the place due to the variable distribution of non-zero coefficients.
2024-07-15 18:19:39 +00:00
} \
lavc/h264dsp: use RISC-V B extension This saves one register and one instruction per transform. add16 and add16intra thus become stack-less.
2024-07-19 19:16:01 +00:00
if (__riscv_xlen == 64 && (flags & AV_CPU_FLAG_RVB)) \
lavc/h264dsp: R-V V high-depth idct_add{,intra}16, idct8_add4 As with 8-bit, this tends to be faster, but results are all over the place due to the variable distribution of non-zero coefficients.
2024-07-15 18:19:39 +00:00
dsp->h264_idct8_add4 = ff_h264_idct8_add4_##depth##_rvv; \
lavc/h264dsp: R-V V high-depth h264_idct8_add Unlike the 8-bit version, we need two iterations to process this within 128-bit vectors. This adds some extra complexity for pointer arithmetic and counting down which is unnecessary in the 8-bit variant. Accordingly the gain relative to C are just slight better than half as good with 128-bit vectors as with 256-bit ones. T-Head C908 (2 iterations): h264_idct8_add_9bpp_c: 17.5 h264_idct8_add_9bpp_rvv_i32: 10.0 h264_idct8_add_10bpp_c: 17.5 h264_idct8_add_10bpp_rvv_i32: 9.7 h264_idct8_add_12bpp_c: 17.7 h264_idct8_add_12bpp_rvv_i32: 9.7 h264_idct8_add_14bpp_c: 17.7 h264_idct8_add_14bpp_rvv_i32: 9.7 SpacemiT X60 (single iteration): h264_idct8_add_9bpp_c: 15.2 h264_idct8_add_9bpp_rvv_i32: 5.0 h264_idct8_add_10bpp_c: 15.2 h264_idct8_add_10bpp_rvv_i32: 5.0 h264_idct8_add_12bpp_c: 14.7 h264_idct8_add_12bpp_rvv_i32: 5.0 h264_idct8_add_14bpp_c: 14.7 h264_idct8_add_14bpp_rvv_i32: 4.7
2024-07-11 19:01:25 +00:00
}
lavc/h264dsp: R-V V high-depth idct_add{,intra}16, idct8_add4 As with 8-bit, this tends to be faster, but results are all over the place due to the variable distribution of non-zero coefficients.
2024-07-15 18:19:39 +00:00
IDCT_DEPTH(9)
IDCT_DEPTH(10)
IDCT_DEPTH(12)
IDCT_DEPTH(14)
lavc/h264dsp: R-V V add_pixels4 and 8-bit add_pixels8 T-Head C908 (cycles): h264_add_pixels4_8bpp_c: 93.5 h264_add_pixels4_8bpp_rvv_i32: 39.5 h264_add_pixels4_9bpp_c: 87.5 h264_add_pixels4_9bpp_rvv_i64: 50.5 h264_add_pixels4_10bpp_c: 87.5 h264_add_pixels4_10bpp_rvv_i64: 50.5 h264_add_pixels4_12bpp_c: 87.5 h264_add_pixels4_12bpp_rvv_i64: 50.5 h264_add_pixels4_14bpp_c: 87.5 h264_add_pixels4_14bpp_rvv_i64: 50.5 h264_add_pixels8_8bpp_c: 265.2 h264_add_pixels8_8bpp_rvv_i64: 84.5
2024-07-13 12:43:27 +00:00
if (bit_depth > 8 && zvl128b) {
lavc/h264dsp: R-V V high-depth add_pixels8 T-Head C908 (cycles); h264_add_pixels8_9bpp_c: 270.5 h264_add_pixels8_9bpp_rvv_i32: 164.2 h264_add_pixels8_10bpp_c: 270.5 h264_add_pixels8_10bpp_rvv_i32: 164.2 h264_add_pixels8_12bpp_c: 270.5 h264_add_pixels8_12bpp_rvv_i32: 164.2 h264_add_pixels8_14bpp_c: 270.5 h264_add_pixels8_14bpp_rvv_i32: 164.2
2024-07-13 13:01:14 +00:00
dsp->h264_add_pixels8_clear = ff_h264_add_pixels8_16_rvv;
lavc/h264dsp: R-V V add_pixels4 and 8-bit add_pixels8 T-Head C908 (cycles): h264_add_pixels4_8bpp_c: 93.5 h264_add_pixels4_8bpp_rvv_i32: 39.5 h264_add_pixels4_9bpp_c: 87.5 h264_add_pixels4_9bpp_rvv_i64: 50.5 h264_add_pixels4_10bpp_c: 87.5 h264_add_pixels4_10bpp_rvv_i64: 50.5 h264_add_pixels4_12bpp_c: 87.5 h264_add_pixels4_12bpp_rvv_i64: 50.5 h264_add_pixels4_14bpp_c: 87.5 h264_add_pixels4_14bpp_rvv_i64: 50.5 h264_add_pixels8_8bpp_c: 265.2 h264_add_pixels8_8bpp_rvv_i64: 84.5
2024-07-13 12:43:27 +00:00
if (flags & AV_CPU_FLAG_RVV_I64)
dsp->h264_add_pixels4_clear = ff_h264_add_pixels4_16_rvv;
}
lavc/h264dsp: R-V V high-depth h264_idct_add T-Head C908 (cycles): h264_idct4_add_9bpp_c: 248.2 h264_idct4_add_9bpp_rvv_i32: 128.7 h264_idct4_add_10bpp_c: 256.7 h264_idct4_add_10bpp_rvv_i32: 128.7 h264_idct4_add_12bpp_c: 252.5 h264_idct4_add_12bpp_rvv_i32: 129.7 h264_idct4_add_14bpp_c: 258.0 h264_idct4_add_14bpp_rvv_i32: 129.7
2024-07-02 19:03:07 +00:00
lavc/startcode: add R-V V startcode_find_candidate
2024-05-12 10:54:33 +00:00
dsp->startcode_find_candidate = ff_startcode_find_candidate_rvv;
lavc/h264dsp: R-V V 8-bit luma loop filter T-Head C908 (cycles): h264_h_loop_filter_luma_8bpp_c: 297.5 h264_h_loop_filter_luma_8bpp_rvv_i32: 369.2 h264_v_loop_filter_luma_8bpp_c: 862.7 h264_v_loop_filter_luma_8bpp_rvv_i32: 199.7 Performance in the horizontal scenario seems worse than scalar. x86 SSE2 and AVX optimisations are similarly affected. This is presumably caused by unlucky inputs from checkasm, such that the C code short-circuits almost all filter calculations.
2024-06-28 18:56:12 +00:00
}
lavc/startcode: add R-V V startcode_find_candidate
2024-05-12 10:54:33 +00:00
# endif
lavc/startcode: add R-V Zbb startcode_find_candidate The main loop processes 8 bytes in 5 instructions. For comparison, the optimal plain strnlen() requires 4 instructions per byte (6.4x worse): LBU; ADDI; BEQZ; BNE. The current libavcodec C code involves 5 instructions per byte (8x worse). Actual benchmarks may be slightly less favourable due to latency from ORC.B to BNE.
2024-05-16 14:13:22 +00:00
#endif
}
Reference in New Issue Copy Permalink