3 ms·

Based on the open source C910, the C920 adds vector acceleration extensions to improve performance for machine learning workloads — but, it must be noted, is ba

Based on the open source C910, the C920 adds vector acceleration extensions to improve performance for machine learning workloads — but, it must be noted, is based around the pre-ratification RISC-V Vector (RVV) 0.71 standard which lacks broad support in compilers.

snvzz 3y ago
Every chip with V in the market so far is based on 0.7.1. Hardware takes time, and V was only ratified in December 2021. The good news is that the first boards based on chips with V are expected before year end. There's Ventana Veyron and there's an unspecified chip in a development board from Sipeed[0]. By next year, I expect a range of RVA22+V chips and boards based on them. Personally, I am looking forward to Tenstorrent's (CEO: Jim Keller) Ascalon, led by Wei-han Lien, who also led the M1 project at Apple, and expected to have similar IPC as projected Zen5 (also TBA 2024) but using significantly less power. It has a range of smaller variants, potentially able to cover a range of products including servers, laptops and smartphones. 0. https://www.hackster.io/news/sipeed-teases-a-40-single-board-computer-with-fully-ratified-risc-v-vector-extensions-446455118f04 https://www.hackster.io/news/sipeed-teases-a-40-single-board...
- CameronNemo 3y ago
  OK, but that doesn't change the fact that if you actually want to use the vector extension on this CPU you'll be using a very out of date compiler, or forward porting the 0.7.1 support to a newer toolchain. For someone buying a quad core SBC that may not be a big deal, but 64 cores that you can't cleanly use to their full potential is a bit of an ask.
  - snvzz 3y ago
    >OK, but that doesn't change the fact that if you actually want to use the vector extension on this CPU you'll be using a very out of date compiler, or forward porting the 0.7.1 support to a newer toolchain. GNU toolchain supports 0.7.1. What we don't know is if it will do so forever, or remove it. >For someone buying a quad core SBC that may not be a big deal, but 64 cores that you can't cleanly use to their full potential is a bit of an ask. However, If a company has a need for this sort of compute and has and full control of their stack, these chips can be useful and are already available. For an enthusiast it's alright as long as not much money is spent (e.g. Sipeed LM4A), at worst (if there ceases to be an ecosystem for 0.7.1 V) what you've got then is a chip with no V. One that's significantly faster than the one used in VisionFive 2, which does actually not have V in any form or shape. For end users that don't care about RISC-V and want an SBC, next year (or perhaps late this year) there'll be RVA22+V options, and a much more mature ecosystem; I own VF2 (the first RISC-V SBC to actually ship large numbers), and I have seen how fast the ecosystem has accelerated since its release.
    - CameronNemo 3y ago
      Do you have a source on GCC supporting v 0.7.1? That is contrary to what I've read.
      - snvzz 3y ago
        On a personal level, I prefer upstream not to have anything non-ratified. Companies that use these should bear the cost of maintaining the toolchain, not upstream. There's this tree[0] which has support. I thought it actually got merged, but I'm currently struggling to find anything about it. 0. https://github.com/brucehoult/riscv-gnu-toolchain/tree/rvv-0.7.1 https://github.com/brucehoult/riscv-gnu-toolchain/tree/rvv-0...
        brucehoult 3y ago
        My repo is relatively old, gcc 9.2.0. Not that there's anything much wrong with gcc from August 2019! I've been using gcc since 2002. THead have a newer version based on gcc 10.2.0. https://github.com/T-head-Semi/xuantie-gnu-toolchain https://github.com/T-head-Semi/xuantie-gnu-toolchain But it doesn't really matter. There is no support in the C language for RVV 0.7.1, you just have to write either plain assembly language or inline asm for your RVV code. Which means you need a binutils that supports RVV 0.7.1 to assemble your vector code, but you can compile the rest of your program with the latest upstream gcc. Then you can link the .o files. Note that even though there is support for RVV 1.0 "intrinsic functions" in C compilers, SiFive just submitted RVV 1.0 support for FFmpeg and it's written in pure assembly language. https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309722.html https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309722.ht...
- brucehoult 3y ago
  "there's an unspecified chip in a development board from Sipeed" The core is specified (C908). The chip is almost certainly Kendryte K230. If Sipeed are saying "hey guys, would anyone buy this?" now then based on past performance you could probably have one in your hands early next year.

snvzz 3y ago

Every chip with V in the market so far is based on 0.7.1. Hardware takes time, and V was only ratified in December 2021. The good news is that the first boards based on chips with V are expected before year end. There's Ventana Veyron and there's an unspecified chip in a development board from Sipeed[0]. By next year, I expect a range of RVA22+V chips and boards based on them. Personally, I am looking forward to Tenstorrent's (CEO: Jim Keller) Ascalon, led by Wei-han Lien, who also led the M1 project at Apple, and expected to have similar IPC as projected Zen5 (also TBA 2024) but using significantly less power. It has a range of smaller variants, potentially able to cover a range of products including servers, laptops and smartphones. 0. https://www.hackster.io/news/sipeed-teases-a-40-single-board-computer-with-fully-ratified-risc-v-vector-extensions-446455118f04 https://www.hackster.io/news/sipeed-teases-a-40-single-board...

CameronNemo 3y ago
OK, but that doesn't change the fact that if you actually want to use the vector extension on this CPU you'll be using a very out of date compiler, or forward porting the 0.7.1 support to a newer toolchain. For someone buying a quad core SBC that may not be a big deal, but 64 cores that you can't cleanly use to their full potential is a bit of an ask.
- snvzz 3y ago
  >OK, but that doesn't change the fact that if you actually want to use the vector extension on this CPU you'll be using a very out of date compiler, or forward porting the 0.7.1 support to a newer toolchain. GNU toolchain supports 0.7.1. What we don't know is if it will do so forever, or remove it. >For someone buying a quad core SBC that may not be a big deal, but 64 cores that you can't cleanly use to their full potential is a bit of an ask. However, If a company has a need for this sort of compute and has and full control of their stack, these chips can be useful and are already available. For an enthusiast it's alright as long as not much money is spent (e.g. Sipeed LM4A), at worst (if there ceases to be an ecosystem for 0.7.1 V) what you've got then is a chip with no V. One that's significantly faster than the one used in VisionFive 2, which does actually not have V in any form or shape. For end users that don't care about RISC-V and want an SBC, next year (or perhaps late this year) there'll be RVA22+V options, and a much more mature ecosystem; I own VF2 (the first RISC-V SBC to actually ship large numbers), and I have seen how fast the ecosystem has accelerated since its release.
  - CameronNemo 3y ago
    Do you have a source on GCC supporting v 0.7.1? That is contrary to what I've read.
    - snvzz 3y ago
      On a personal level, I prefer upstream not to have anything non-ratified. Companies that use these should bear the cost of maintaining the toolchain, not upstream. There's this tree[0] which has support. I thought it actually got merged, but I'm currently struggling to find anything about it. 0. https://github.com/brucehoult/riscv-gnu-toolchain/tree/rvv-0.7.1 https://github.com/brucehoult/riscv-gnu-toolchain/tree/rvv-0...
      - brucehoult 3y ago
        My repo is relatively old, gcc 9.2.0. Not that there's anything much wrong with gcc from August 2019! I've been using gcc since 2002. THead have a newer version based on gcc 10.2.0. https://github.com/T-head-Semi/xuantie-gnu-toolchain https://github.com/T-head-Semi/xuantie-gnu-toolchain But it doesn't really matter. There is no support in the C language for RVV 0.7.1, you just have to write either plain assembly language or inline asm for your RVV code. Which means you need a binutils that supports RVV 0.7.1 to assemble your vector code, but you can compile the rest of your program with the latest upstream gcc. Then you can link the .o files. Note that even though there is support for RVV 1.0 "intrinsic functions" in C compilers, SiFive just submitted RVV 1.0 support for FFmpeg and it's written in pure assembly language. https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309722.html https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309722.ht...
brucehoult 3y ago
"there's an unspecified chip in a development board from Sipeed" The core is specified (C908). The chip is almost certainly Kendryte K230. If Sipeed are saying "hey guys, would anyone buy this?" now then based on past performance you could probably have one in your hands early next year.