6 ms·

riscv64 is now an official Debian architecture (rebootstrap in progress)

135 points by pabs3 3y ago

stevefan1999 3y ago
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
kosolam 3y ago
Sounds exciting. I haven’t figured yet how I can make use of riscv but my hands are scratching and I’m an avid debian user. Anyone here does interesting hobby projects with riscv hardware?
jeffbee 3y ago
It's interesting that the project officially supports riscv64 but other architectures in a similar ecosystem niche, but vastly larger installed base, like SH4, have been unofficial ports for decades. Perhaps this is a good comparative example of how to effectively engage the community, or fail to.
- orra 3y ago
  I can't speak for why SH4 was always unofficial, but from a vibes perspective today, RISC-V feels like an architecture on the up. That probably helps attract more developers, and ultimately it takes people to do the work.
- lambda 3y ago
  Where are you getting the "vastly larger installed base"? On popcon riscv64 is a lot higher than sh4: https://popcon.debian.org/stat/submission-1year.png https://popcon.debian.org/stat/submission-1year.png There may be more hardware out there with SH4 processors, like some NAS boxes, but are they using or contributing to Debian? And when I look at a list of hardware with SuperH processors, half of the links are broken links: https://elinux.org/Processors#SuperH https://elinux.org/Processors#SuperH SuperH seems like a niche architecture mostly supported by a single vendor and available in a few devices mostly in the Japanese market, without a huge amount of use in the Debian community. RISC-V may not yet have as much extant hardware available, but there's tons of active development, and the open licensing model means that a lot of companies are working on RISC-V chips, which will then flow into hardware.
  - jeffbee 3y ago
    I'm not suggesting that SuperH would become an official port today when it is clearly dead. But the question is why it was never an official port even when it was in its prime. As for the installed base, it is absolutely terrifyingly large. They had a lot of wins in automotive, and popular consumer products like Sonos are based on it, or were for the first decade of that product line, and those products also run Linux.
    - 3y ago
beebmam 3y ago
Where would I go about buying a serious risc-v PC? So far, all I've seen are either tiny devices without much computation power, or emulation support. Is risc-v a legitimate platform for serious computation or is it targeted at embedded devices?
- snvzz 3y ago
  If you want to play with running Linux on RISC-V today or doing any porting work, VisionFive2 is where it's at. They are serious about upstream support[0]. 0. https://rvspace.org/en/project/JH7110_Upstream_Plan https://rvspace.org/en/project/JH7110_Upstream_Plan
- saagarjha 3y ago
  There are people working to make server-level chips for it but none of them are really quite ready yet.
  - snvzz 3y ago
    Ventana Veyron is due before year end. Tenstorrent Ascalon (led by who was Apple M1 lead architect) promises competitive performance with projected AMD Zen5, and is due 2024 (same as Zen5).
    - imtringued 3y ago
      ARM had decades to get into the server market and they are still struggling. Sure AWS' server instances are reasonably good but competitive RISC-V server hardware will be coming out over the next five years and then it is over for ARM. I personally thought that Microsoft was going to abandon x86 for ARM in 2017 because it means they can lock the platform down even further with applications only being installable from their proprietary store and the bootloader being locked to windows only. Six years later nothing happened. ARM is on its deathbed.
      - snvzz 3y ago
        re: AWS, I wouldn't be surprised if the next iteration of graviton is RISC-V, or the one after.
zX41ZdbW 3y ago
We have recently added official builds of ClickHouse for RISCV-64: https://github.com/ClickHouse/ClickHouse/pull/31398 https://github.com/ClickHouse/ClickHouse/pull/31398 Although the support existed for several years, it was not automated until recently.
- pabs3 3y ago
  What build hardware are you using for riscv64?
  - zX41ZdbW 3y ago
    We are doing cross-compilation, and all the targets can be built on x86_64 or aarch64 servers or laptops/desktops; in the CI, we are using x86_64 machines in AWS.
rwmj 3y ago
Why are they "rebootstapping"? Or does that mean they're just recompiling all the .debs again, but using the existing environment? (For context I've bootstrapped Fedora on riscv64 from scratch three times, and I wouldn't be keen to ever have to do it again.)
- snvzz 3y ago
  Debian unofficial ports are built separately. As RISC-V is now official, it needs to be rebuilt with the infrastructure that builds all official architectures. There should be no issues, as the unofficial port is already building over 95% of the Debian package library. Note that Debian is the biggest distribution, so this is no small feat. In a couple weeks, it should all be sorted, with the official port built to the same level the unofficial port was.
  - rwmj 3y ago
    Sure, we also build most of Fedora on a separate build system (http://fedora.riscv.rocks/koji/ http://fedora.riscv.rocks/koji/) so it's a pretty similar situation.
    - pabs3 3y ago
      By built separately, they meant unofficial ports aren't built by Debian, but by random machines hosted in random places by members of the port team, who often aren't Debian members yet.
- pabs3 3y ago
  The rebootstrap is done because unofficial ports build servers usually are not owned or run by the Debian project, but by the porting teams themselves, who could be and often are random people who are not yet Debian members. So we don't necessarily want to use all of those .debs because they might not be rebuildable, or they might have artefacts from whatever hacky bootstrap process the first build used. The bootstrap process is a QA strategy to have more trust in the resulting binary packages. Longer term we want all new ports to be cross-built from an existing architecture, but we don't have cross-buildds yet. The rebootstrap tool is a work-in-progress QA tool for making cross-building bootstrap for new arches a viable strategy. https://wiki.debian.org/HelmutGrohne/rebootstrap https://wiki.debian.org/HelmutGrohne/rebootstrap https://wiki.debian.org/DebianBootstrap https://wiki.debian.org/DebianBootstrap https://crossqa.debian.net/ https://crossqa.debian.net/ https://wiki.debian.org/PortsDocs/New https://wiki.debian.org/PortsDocs/New Even longer term, we should do a bootstrap of all architectures from scratch using the approach of Guix, Bootstrappable Builds and Reproducible Builds; start with ~500 bytes of hand-written machine code plus all the source code and build enough to get a build server up, then go from there. https://bootstrappable.org/ https://bootstrappable.org/ https://reproducible-builds.org/ https://reproducible-builds.org/ https://www.aikidev.net/~vagrant/talks/2023/fossy/Breaking_the_Chains_of_Trusting_Trust.pdf https://www.aikidev.net/~vagrant/talks/2023/fossy/Breaking_t...

135 points by pabs3 3y ago

stevefan1999 3y ago

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

kosolam 3y ago

Sounds exciting. I haven’t figured yet how I can make use of riscv but my hands are scratching and I’m an avid debian user. Anyone here does interesting hobby projects with riscv hardware?

jeffbee 3y ago

It's interesting that the project officially supports riscv64 but other architectures in a similar ecosystem niche, but vastly larger installed base, like SH4, have been unofficial ports for decades. Perhaps this is a good comparative example of how to effectively engage the community, or fail to.

orra 3y ago
I can't speak for why SH4 was always unofficial, but from a vibes perspective today, RISC-V feels like an architecture on the up. That probably helps attract more developers, and ultimately it takes people to do the work.
lambda 3y ago
Where are you getting the "vastly larger installed base"? On popcon riscv64 is a lot higher than sh4: https://popcon.debian.org/stat/submission-1year.png https://popcon.debian.org/stat/submission-1year.png There may be more hardware out there with SH4 processors, like some NAS boxes, but are they using or contributing to Debian? And when I look at a list of hardware with SuperH processors, half of the links are broken links: https://elinux.org/Processors#SuperH https://elinux.org/Processors#SuperH SuperH seems like a niche architecture mostly supported by a single vendor and available in a few devices mostly in the Japanese market, without a huge amount of use in the Debian community. RISC-V may not yet have as much extant hardware available, but there's tons of active development, and the open licensing model means that a lot of companies are working on RISC-V chips, which will then flow into hardware.
- jeffbee 3y ago
  I'm not suggesting that SuperH would become an official port today when it is clearly dead. But the question is why it was never an official port even when it was in its prime. As for the installed base, it is absolutely terrifyingly large. They had a lot of wins in automotive, and popular consumer products like Sonos are based on it, or were for the first decade of that product line, and those products also run Linux.
  - 3y ago

beebmam 3y ago

Where would I go about buying a serious risc-v PC? So far, all I've seen are either tiny devices without much computation power, or emulation support. Is risc-v a legitimate platform for serious computation or is it targeted at embedded devices?

snvzz 3y ago
If you want to play with running Linux on RISC-V today or doing any porting work, VisionFive2 is where it's at. They are serious about upstream support[0]. 0. https://rvspace.org/en/project/JH7110_Upstream_Plan https://rvspace.org/en/project/JH7110_Upstream_Plan
saagarjha 3y ago
There are people working to make server-level chips for it but none of them are really quite ready yet.
- snvzz 3y ago
  Ventana Veyron is due before year end. Tenstorrent Ascalon (led by who was Apple M1 lead architect) promises competitive performance with projected AMD Zen5, and is due 2024 (same as Zen5).
  - imtringued 3y ago
    ARM had decades to get into the server market and they are still struggling. Sure AWS' server instances are reasonably good but competitive RISC-V server hardware will be coming out over the next five years and then it is over for ARM. I personally thought that Microsoft was going to abandon x86 for ARM in 2017 because it means they can lock the platform down even further with applications only being installable from their proprietary store and the bootloader being locked to windows only. Six years later nothing happened. ARM is on its deathbed.
    - snvzz 3y ago
      re: AWS, I wouldn't be surprised if the next iteration of graviton is RISC-V, or the one after.

zX41ZdbW 3y ago

We have recently added official builds of ClickHouse for RISCV-64: https://github.com/ClickHouse/ClickHouse/pull/31398 https://github.com/ClickHouse/ClickHouse/pull/31398 Although the support existed for several years, it was not automated until recently.

pabs3 3y ago
What build hardware are you using for riscv64?
- zX41ZdbW 3y ago
  We are doing cross-compilation, and all the targets can be built on x86_64 or aarch64 servers or laptops/desktops; in the CI, we are using x86_64 machines in AWS.

rwmj 3y ago

Why are they "rebootstapping"? Or does that mean they're just recompiling all the .debs again, but using the existing environment? (For context I've bootstrapped Fedora on riscv64 from scratch three times, and I wouldn't be keen to ever have to do it again.)

snvzz 3y ago
Debian unofficial ports are built separately. As RISC-V is now official, it needs to be rebuilt with the infrastructure that builds all official architectures. There should be no issues, as the unofficial port is already building over 95% of the Debian package library. Note that Debian is the biggest distribution, so this is no small feat. In a couple weeks, it should all be sorted, with the official port built to the same level the unofficial port was.
- rwmj 3y ago
  Sure, we also build most of Fedora on a separate build system (http://fedora.riscv.rocks/koji/ http://fedora.riscv.rocks/koji/) so it's a pretty similar situation.
  - pabs3 3y ago
    By built separately, they meant unofficial ports aren't built by Debian, but by random machines hosted in random places by members of the port team, who often aren't Debian members yet.
pabs3 3y ago
The rebootstrap is done because unofficial ports build servers usually are not owned or run by the Debian project, but by the porting teams themselves, who could be and often are random people who are not yet Debian members. So we don't necessarily want to use all of those .debs because they might not be rebuildable, or they might have artefacts from whatever hacky bootstrap process the first build used. The bootstrap process is a QA strategy to have more trust in the resulting binary packages. Longer term we want all new ports to be cross-built from an existing architecture, but we don't have cross-buildds yet. The rebootstrap tool is a work-in-progress QA tool for making cross-building bootstrap for new arches a viable strategy. https://wiki.debian.org/HelmutGrohne/rebootstrap https://wiki.debian.org/HelmutGrohne/rebootstrap https://wiki.debian.org/DebianBootstrap https://wiki.debian.org/DebianBootstrap https://crossqa.debian.net/ https://crossqa.debian.net/ https://wiki.debian.org/PortsDocs/New https://wiki.debian.org/PortsDocs/New Even longer term, we should do a bootstrap of all architectures from scratch using the approach of Guix, Bootstrappable Builds and Reproducible Builds; start with ~500 bytes of hand-written machine code plus all the source code and build enough to get a build server up, then go from there. https://bootstrappable.org/ https://bootstrappable.org/ https://reproducible-builds.org/ https://reproducible-builds.org/ https://www.aikidev.net/~vagrant/talks/2023/fossy/Breaking_the_Chains_of_Trusting_Trust.pdf https://www.aikidev.net/~vagrant/talks/2023/fossy/Breaking_t...