Hacker News Reader

Comment by stevefan1999 | Hacker News Reader

stevefan1999

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

View on HN

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...

[1] https://twitter.com/SipeedIO/status/1654055669774036993

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

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.

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.ht...

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.

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.

riscv provides a vector unit instead of a traditional simd

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-v-spec/

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.

There dosent seem to be a lot of demand for it

Debian would target typical linux application usage

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).

Reply on news.ycombinator.com