RISC-V port implementation

[k-kisielak]

I want to announce that we are currently working on RISC-V implementation using vector extension.
As we I mean: Samsung R&D Poland + partially RISE Project engineers

Code is being developed on feature branch at: https://github.com/k-kisielak/opus/tree/rvv_impl
Implementation is in early stage and is not deemed for merging in current form.

Current state:
We started with implementing parts of silk module:

• basing on existing SSE implementation we prepared one using RISC-V vector intrinsics

Items under development:

• tests are to be performed, both functional and performance ones - to test those changes we have access to RISC-V devices like BananaPI F3, we have experience with testing RVV under qemu
• we are looking into expanding github action configs to allow testing RISC-V version (as of now only on linux)
• we are integrating more RVV implementations, namely for burg modified algorithm

We would gladly accept any feedback, thank you!

[petterreinholdtsen]

[Krystian Kisielak]

We would gladly accept any feedback, thank you!

I can not really help with the code, but can tell you I am very happy to read that you are working on an optimized RISC-V implementation. Keep up the good work. :)

…

-- Happy hacking Petter Reinholdtsen

[jmvalin]

This is indeed good news. Here's a few questions/suggestions on how to proceed:

1. Are you targeting fixed-point or floating point or both? On some devices one is faster than the other, but it's not always the same. All things being equal float is generally preferable because it has more features.
2. When optimizing, it's best to start with just defining optimized version of some of the basic operations. For example, you can look at celt/arm/fixed_armv4.h and silk/arm/macros_armv5e.h. That's an easy way to optimize many functions at once without changing too much code.
3. If optimizing entire function, replicating something similar to SSE/ARM like you're doing is a good idea. Make sure you implement the CHECK_ASM scheme for debugging with --enable-check-asm
4. Splitting into small patches that each add functionality without regressions (e.g. optimize one function and use it) is the best way to land these changes.

[k-kisielak]

Ad.1 We are opting for 'somewhat capable' devices with vector units operating on floats. So fixed point is less important.
Ad. 2-4 Thank you for your advice, as of now we focused on bulky functions yet we will look for ones which could provide speedup with small changes exploiting vector extension capabilities.

[jmvalin]

The first thing I would check is whether you want to set OPUS_FAST_INT64 to 0 or 1 in celt/arch.h. For float, it will not make a difference for CELT, but it will have an impact on SILK. So you might want to pick whichever value makes SILK run the fastest before you optimize (because that changes the exact behaviour).

[MarekPikula]

Hi all, I'm part of the team working on Opus RVV backend at Samsung, currently focusing on the autodiscovery mechanism.

I'm a little bit baffled by the amount of build systems used by this project. I can see Autotools, CMake and Meson in play. Do you expect us to simultaneously introduce support for all build systems, or is there a single one which we should focus on for the time being? As far as I understand, CMake is used mainly for Windows builds, and Meson was introduced quite recently. Are Autotools being phased out, or they're still considered a first-class citizen? To be honest, I'd prefer to use Meson exclusively if possible.

The second thing is the CI setup. I can see that you're using both GitHub and GitLab for that, with varying extent of tests performed by each. Which one should we use to introduce RISC-V CI tests? What would be your preferred way of doing that? We have experience with using Docker+QEMU to run tests for various RVV configurations (see https://gitlab.freedesktop.org/pixman/pixman).

By the way, do you prefer the discussion and contribution to happen here, or on your GitLab instance?

[jmvalin]

Hi, No need to simultaneously add support to all build systems. Right now autotools is definitely first-class citizen and probably the most widely used by Opus developers. But it's fine to add RISC-V support that's Meson-only for now and if people care about having it with other build systems, they can always port it. The only hard condition is to not break other build systems or make them harder to maintain.

In terms of CI, I'm not familiar with either the GitHub or GitLab systems and have my own (much more compute intensive) scripts I'll run less frequently. So I don't have a strong opinion on that.

As for the discussion, either GitLab or GitHub is fine -- whichever is easiest for you guys.

[MarekPikula]

All right, that's good to know. I just realized that Autotools are used to build libopus in Tizen (which is our main interest), so as much as it pains me, I'll use Autotools for now. The important thing for me is that it can be a single build system for now, which is good.

In terms of CI, I'm not familiar with either the GitHub or GitLab systems and have my own (much more compute intensive) scripts I'll run less frequently. So I don't have a strong opinion on that.

Are these scripts published somewhere, and should we introduce support for RISC-V in them as well?

Are you aware if your GitLab runners support Docker+QEMU execution (using binfmt)? I could check it myself, but it seems that creating a repository on a new account is blocked (my username is MarekPikula).

[rillian]

Are you aware if your GitLab runners support Docker+QEMU execution (using binfmt)?

Our GitLab runners can invoke general linux containers, so if it's something you can set up for emulation testing we should be able to do it there.

[rillian]

I could check it myself, but

I bumped your project quota, so you should be able to fork on gitlab.xiph.org now. Turning on CI may require separate admin review though.

[MarekPikula]

Perfect, thanks a lot.

It seems that the runners can execute non-native Docker images (https://gitlab.xiph.org/MarekPikula/opus/-/jobs/26134), so RISC-V CI support is possible with the current infra.