[FFmpeg-devel] [RFC] [PATCH 0/7] RISC-V V vector length dealings

Rémi Denis-Courmont remi at remlab.net
Tue Sep 27 23:04:08 EEST 2022


	Hello,

As a general rule, scalable vector instruction sets should be used with the
largest possible vector length. There are however a number of operations that
just happen with a fixed size, and this patchset exhibits the simplest one I
could find. The proper RISC-V Vector extension guarantees a minimum vector
length of 128 bits. In theory though the underlying specification also allows
for (embedded designs with) only 32 or 64 bits per vector.

The RFC is how should this be dealt with? The simplest possibibility is to
simply assume 128 bits. Indeed, I am not aware of any actual or proposed
processor IP with shorter-than-128-bit vectors, even less so, one upon which
FFmpeg would be used. For what it is worth, ARM SVE guarantees a minimum of
128 bits per vector too. In that case, we can drop the first patch, and
simplify the following ones.

Another option is to expose the vector length via the CPU flags as proposed
earlier by Lynne. Though this is unorthodox the vector length is not a proper
flag. The vector length can readily be retrieved from a read-only unprivileged
CSR, and this patchset instead introduces a simple inline wrapper therefore.
The downside of this approach is that this is nominally undefined behaviour,
and typically will raise a SIGILL, if the processor does not support the
vector extension.

However I want to emphasise that the same problem also exists for DSP
functions operating on more than 128 bits. For instance, the inner loop of the
Opus post-filter works with 160 bits. So then, we cannot simply ignore the
variability between processors. RISC-V has existing designs with 128-bit
vectors and announced designs with 256-bit and 512-bit vectors.

I don't personally have any strong preference for or against either of the CPU
flags or the dedicated platform-specific helper approaches. And besides, I do
not have the pretense to decide on FFmpeg internal design. But I doubt that
this concern can be ignored entirely.

The following changes since commit 59cb0bd23d61f6ea3bfd86558346e2720aba7f06:

  avfilter/vf_extractplanes: add missing break; statement (2022-09-27 19:35:49 +0200)

are available in the Git repository at:

  https://git.remlab.net/git/ffmpeg.git rvv-vlen

for you to fetch changes up to 1b80effc9798c164fd7c1953174ccf4a66298aff:

  lavc/pixblockdsp: RISC-V diff_pixels & diff_pixels_unaligned (2022-09-27 22:19:19 +0300)

----------------------------------------------------------------
Rémi Denis-Courmont (7):
      lavu/riscv: helper to read the vector length
      lavc/idctdsp: RISC-V V put_pixels_clamped function
      lavc/idctdsp: RISC-V V add_pixels_clamped function
      lavc/idctdsp: RISC-V V put_signed_pixels_clamped function
      lavc/pixblockdsp: RISC-V V 8-bit get_pixels & get_pixels_unaligned
      lavc/pixblockdsp: RISC-V V 16-bit get_pixels & get_pixels_unaligned
      lavc/pixblockdsp: RISC-V diff_pixels & diff_pixels_unaligned

 libavcodec/idctdsp.c                |  2 +
 libavcodec/idctdsp.h                |  2 +
 libavcodec/riscv/Makefile           |  3 ++
 libavcodec/riscv/idctdsp_init.c     | 48 ++++++++++++++++++++++
 libavcodec/riscv/idctdsp_rvv.S      | 80 +++++++++++++++++++++++++++++++++++++
 libavcodec/riscv/pixblockdsp_init.c | 20 ++++++++++
 libavcodec/riscv/pixblockdsp_rvv.S  | 60 ++++++++++++++++++++++++++++
 libavutil/riscv/cpu.h               | 45 +++++++++++++++++++++
 8 files changed, 260 insertions(+)
 create mode 100644 libavcodec/riscv/idctdsp_init.c
 create mode 100644 libavcodec/riscv/idctdsp_rvv.S
 create mode 100644 libavcodec/riscv/pixblockdsp_rvv.S
 create mode 100644 libavutil/riscv/cpu.h

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/





More information about the ffmpeg-devel mailing list