4 ms·

What about SIMD support? Most software (like ffmpeg) clearly aren't having nor is going to use the current SIMD specification for rv64

by stevefan1999 3y ago

tsukikage 3y ago
ToT llvm autovectorisation for riscv "V" 1.0 is actually really rather decent. Not as good as handcoding, natch, but can get to within a factor of two or better especially on workloads which are mostly simple tiny loops over data that's contiguous or has constant stride, as in h264 encoding. Of course, the question is somewhat moot until we have development hardware available to buy that supports the ratified 1.0 version of the vector extensions. So, another year or so I'd guess.
photonbeam 3y ago
riscv provides a vector unit instead of a traditional simd
- cbm-vic-20 3y ago
  I thought I had read somewhere that the Packed SIMD (P) extension was still going to be developed for implementations that don't need the full-blown Vector (V) extension, for example, embedded processors for digital signal processing. https://github.com/riscv/riscv-p-spec/ https://github.com/riscv/riscv-p-spec/ https://github.com/riscv/riscv-v-spec/ https://github.com/riscv/riscv-v-spec/
  - photonbeam 3y ago
    There dosent seem to be a lot of demand for it Debian would target typical linux application usage
  - dzaima 3y ago
    The P extension is quite "small" though - it works in the regular 32/64-bit x1-x31 GPRs, which is also pretty far from traditional SIMD.
  - snvzz 3y ago
    The packed SIMD effort hasn't moved in years, as there's no interest (commercial or otherwise). This is in no small part due to the ratified V extension scaling well in both directions (smaller and larger designs).
dzaima 3y ago
rvv1.0 is frozen, and ffmpeg does contain some usage of it: https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcodec/riscv https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcod...
- arp242 3y ago
  To contextualize this – because I had no idea if those 13 files constituted "a lot", "very little", or anything in between – here's a comparison of amount of asm code for each platform: Files Lines Blanks Comments Code aarch64 35 24,703 1,999 0 22,704 alpha 3 471 57 0 414 arm 69 30,600 1,975 0 28,625 loongarch 6 6,531 485 0 6,046 ppc 2 605 50 0 555 riscv 13 1,284 71 0 1,213 x86 97 48,669 4,260 4418 39,991 This is a very rough comparison and doesn't take in to account the C code for every platform (which seems to scale roughly but not exactly the same), programming style, architecture differences, etc. but it should be roughly accurate.
  - camel-cdr 3y ago
    There are also these h264 patches floating around, but I don't think they have been fully merged yet: https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309386.html https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309386.ht...
leonheld 3y ago
This is the real issue with adopting new architectures, imho. So many packages claim to support arm, for example, whilst not enabling the proper optimisation flags, rendering it unusable. A loooot of work we take for granted has been put to optimize things for x86.
camel-cdr 3y ago
The packed simd extension isn't ratified and mostly aimed at embedded processors that need to do digital signal processing. The vector extension (rvv) is what's important for desktop and server chips, and it is already ratified. ffmpeg for example already has some things ported to rvv [0], and many projects are already working on support. The problem is that there currently isn't any consumer hardware that supports the ratified vector extension. Sipeed announced [1] that they are working on a RVA22+V soc based on the C908 chip, this will likely be the first one developers can get their hands on. [0] https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcod https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcod... [1] https://twitter.com/SipeedIO/status/1654055669774036993 https://twitter.com/SipeedIO/status/1654055669774036993

What about SIMD support? Most software (like ffmpeg) clearly aren't having nor is going to use the current SIMD specification for rv64

tsukikage 3y ago

ToT llvm autovectorisation for riscv "V" 1.0 is actually really rather decent. Not as good as handcoding, natch, but can get to within a factor of two or better especially on workloads which are mostly simple tiny loops over data that's contiguous or has constant stride, as in h264 encoding. Of course, the question is somewhat moot until we have development hardware available to buy that supports the ratified 1.0 version of the vector extensions. So, another year or so I'd guess.

photonbeam 3y ago

riscv provides a vector unit instead of a traditional simd

cbm-vic-20 3y ago
I thought I had read somewhere that the Packed SIMD (P) extension was still going to be developed for implementations that don't need the full-blown Vector (V) extension, for example, embedded processors for digital signal processing. https://github.com/riscv/riscv-p-spec/ https://github.com/riscv/riscv-p-spec/ https://github.com/riscv/riscv-v-spec/ https://github.com/riscv/riscv-v-spec/
- photonbeam 3y ago
  There dosent seem to be a lot of demand for it Debian would target typical linux application usage
- dzaima 3y ago
  The P extension is quite "small" though - it works in the regular 32/64-bit x1-x31 GPRs, which is also pretty far from traditional SIMD.
- snvzz 3y ago
  The packed SIMD effort hasn't moved in years, as there's no interest (commercial or otherwise). This is in no small part due to the ratified V extension scaling well in both directions (smaller and larger designs).

dzaima 3y ago

rvv1.0 is frozen, and ffmpeg does contain some usage of it: https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcodec/riscv https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcod...

arp242 3y ago
To contextualize this – because I had no idea if those 13 files constituted "a lot", "very little", or anything in between – here's a comparison of amount of asm code for each platform: Files Lines Blanks Comments Code aarch64 35 24,703 1,999 0 22,704 alpha 3 471 57 0 414 arm 69 30,600 1,975 0 28,625 loongarch 6 6,531 485 0 6,046 ppc 2 605 50 0 555 riscv 13 1,284 71 0 1,213 x86 97 48,669 4,260 4418 39,991 This is a very rough comparison and doesn't take in to account the C code for every platform (which seems to scale roughly but not exactly the same), programming style, architecture differences, etc. but it should be roughly accurate.
- camel-cdr 3y ago
  There are also these h264 patches floating around, but I don't think they have been fully merged yet: https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309386.html https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309386.ht...

leonheld 3y ago

This is the real issue with adopting new architectures, imho. So many packages claim to support arm, for example, whilst not enabling the proper optimisation flags, rendering it unusable. A loooot of work we take for granted has been put to optimize things for x86.

camel-cdr 3y ago

The packed simd extension isn't ratified and mostly aimed at embedded processors that need to do digital signal processing. The vector extension (rvv) is what's important for desktop and server chips, and it is already ratified. ffmpeg for example already has some things ported to rvv [0], and many projects are already working on support. The problem is that there currently isn't any consumer hardware that supports the ratified vector extension. Sipeed announced [1] that they are working on a RVA22+V soc based on the C908 chip, this will likely be the first one developers can get their hands on. [0] https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcod https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcod... [1] https://twitter.com/SipeedIO/status/1654055669774036993 https://twitter.com/SipeedIO/status/1654055669774036993