4 ms·

> Soon we’ll see many new 64-bit RISC-V SBCs based on the Sophgo SG2000 RISC-V SoC. This is an extremely unusual SoC with three main CPU cores with heterogenou

by mappu 2y ago

> Soon we’ll see many new 64-bit RISC-V SBCs based on the Sophgo SG2000 RISC-V SoC. This is an extremely unusual SoC with three main CPU cores with heterogenous ISA; 1 GHz C906 RISC-V, 1 GHz ARM Cortex-A53, and an extra 700 MHz C906 RISC-V core. You can choose only one of the 1GHz C906 or A53 cores to be active, and the 700 MHz core is additionally active. It also has an MCU, an NPU, and boards are $8. The Xuantie C906 has been incredibly popular core for years now, it's not clear when a successor will appear and the RVV 0.7 debacle still has no end in sight. The A53 has also been surprisingly longevious despite having official successors - either the A55/A510/etc license for a lot more, or the A53 RTL is just floating on GitHub somewhere.

brucehoult 2y ago
> You can choose only one of the 1GHz C906 or A53 cores to be active I know a guy who is reverse-engineering the boot ROM and is writing replacement code in Rust (blergh) that already enables either C906 or A53 to be booted (the A53 was only a theoretical possibility with official software released so far). He says it's not obvious that both can't run at the same time. I expect we'll know in a week or two if he is successful. > the RVV 0.7 debacle still has no end in sight. What debacle? The C906 and C910 vector units implement what was the official draft RVV at the time they were designed. Krste wrote at the time "We think we're very near to the final spec". That turned out to be 2.5 years premature, but all the same 0.7.1 and 1.0 are very very similar (much more so than they are to 0.6 or 0.5 or other SIMD/Vector ISAs such as AVX or SVE), much useful code is binary compatible between them (e.g. all the C library string functions, memcpy etc), and anything at all you write for 0.7.1 can be trivially updated to 1.0 compatibility. Even better, the recently released GCC 14 supports both (0.7.1 under the name "XTHeadVector") and if you write code using the C vector intrinsic functions then GCC can generate code for either version from the exact same source code with only makefile / compiler flag changes. We have two different RVV 1.0 implementations in the market now (I mean boards / chips you can buy and regular customers already have), with more coming this year. BUT, there will continue to be new C906 and maybe C910 boards for probably the next five years. And that is really not the problem some people seem to think it is. They are far more compatible than say, AVX and AVX-512, or AVX and SSE.
- mappu 2y ago
  Thanks for the update - IMO the debacle ranges over the last 4 years or so, where GCC refused to upstream support for RVV 0.7 until now (14.1) and that only living in out-of-tree vendor toolchains, and so all the most popular boards (all with C906/C910) were unable to run RVV binaries compiled with standard distro-packaged GCC. Thus making the vector unit largely useless without a custom toolchain or (more likely) whole BSP/rootfs. My ideal would be if the ordinary Debian binary port could make something useful out of either RVV version if present, without needing a special board rootfs or custom glibc build. > much useful code is binary compatible between them (e.g. all the C library string functions, memcpy etc) I didn't realize common libc functions could be made binary compatible between RVV 0.7 and 1.0, that sounds extremely promising for glibc. I had a quick glance at the glibc source code and didn't find anything other than a C implementation - do you know if that's a recent innovation or what version of glibc supports that? Or is any V implementation in glibc's string functions just relying on the compiler autovectorization (does that exist for RVV)? Or is this not upstream yet? The x86_64 version of this logic is in sysdeps/x86_64/stpcpy.S , it automatically switches to a sse2/avx2/evex implementation if those ISA extensions are present. It looks like the Linux kernel's memcpy does not attempt to use V at all neither (as of 6.9 arch/riscv/lib/memcpy.S),
  - rwmj 2y ago
    > I had a quick glance at the glibc source code and didn't find anything other than a C implementation - do you know if that's a recent innovation or what version of glibc supports that? Or is any V implementation in glibc's string functions just relying on the compiler autovectorization (does that exist for RVV)? Or is this not upstream yet? Last I heard the glibc developers are waiting for a decent hardware platform to target. You need something that supports V1.0, is widely available, and performs something like we expect future hardware to perform so you don't end up optimizing for the wrong things. (Qemu is no use because the performance of emulated V is very different from the real thing since every V instruction goes through a TCG helper function.)
  - brucehoult 2y ago
    > GCC refused to upstream support for RVV 0.7 until now IMHO the GCC people were being dumb. They don't want to upstream support for "draft" specs. That's fundamentally because it will be obsolete as soon as there's a new draft. But that should go out the window as soon as someone makes commercial hardware using that spec -- at that point it's frozen and those real-world users have a right to expect hardware they paid for to be supported. There was also the qustion of who will do the work, and THead and Allwinner and other interested parties in China were not quick to step up to do it. > I didn't realize common libc functions could be made binary compatible between RVV 0.7 and 1.0 Sure. For example here is something I posted in April 2021, tested on a prototype AWOL Nezha D1 board I got ssh access to in China a few months before customers started to receive them in late June / early July. https://hoult.org/d1_memcpy.txt https://hoult.org/d1_memcpy.txt Of course RVV 1.0 was not final then. But it turns out that if you change the `vlb.v` instruction to `vlbu.v` (which doesn't change the functionality as it's loading bytes in RAM to bytes in a vector register) then that maps to `vle8.v` in RVV 1.0. All the other instructions used are binary compatible with the equivalent RVV 1.0 instruction.

by mappu 2y ago

brucehoult 2y ago

> You can choose only one of the 1GHz C906 or A53 cores to be active I know a guy who is reverse-engineering the boot ROM and is writing replacement code in Rust (blergh) that already enables either C906 or A53 to be booted (the A53 was only a theoretical possibility with official software released so far). He says it's not obvious that both can't run at the same time. I expect we'll know in a week or two if he is successful. > the RVV 0.7 debacle still has no end in sight. What debacle? The C906 and C910 vector units implement what was the official draft RVV at the time they were designed. Krste wrote at the time "We think we're very near to the final spec". That turned out to be 2.5 years premature, but all the same 0.7.1 and 1.0 are very very similar (much more so than they are to 0.6 or 0.5 or other SIMD/Vector ISAs such as AVX or SVE), much useful code is binary compatible between them (e.g. all the C library string functions, memcpy etc), and anything at all you write for 0.7.1 can be trivially updated to 1.0 compatibility. Even better, the recently released GCC 14 supports both (0.7.1 under the name "XTHeadVector") and if you write code using the C vector intrinsic functions then GCC can generate code for either version from the exact same source code with only makefile / compiler flag changes. We have two different RVV 1.0 implementations in the market now (I mean boards / chips you can buy and regular customers already have), with more coming this year. BUT, there will continue to be new C906 and maybe C910 boards for probably the next five years. And that is really not the problem some people seem to think it is. They are far more compatible than say, AVX and AVX-512, or AVX and SSE.

mappu 2y ago
Thanks for the update - IMO the debacle ranges over the last 4 years or so, where GCC refused to upstream support for RVV 0.7 until now (14.1) and that only living in out-of-tree vendor toolchains, and so all the most popular boards (all with C906/C910) were unable to run RVV binaries compiled with standard distro-packaged GCC. Thus making the vector unit largely useless without a custom toolchain or (more likely) whole BSP/rootfs. My ideal would be if the ordinary Debian binary port could make something useful out of either RVV version if present, without needing a special board rootfs or custom glibc build. > much useful code is binary compatible between them (e.g. all the C library string functions, memcpy etc) I didn't realize common libc functions could be made binary compatible between RVV 0.7 and 1.0, that sounds extremely promising for glibc. I had a quick glance at the glibc source code and didn't find anything other than a C implementation - do you know if that's a recent innovation or what version of glibc supports that? Or is any V implementation in glibc's string functions just relying on the compiler autovectorization (does that exist for RVV)? Or is this not upstream yet? The x86_64 version of this logic is in sysdeps/x86_64/stpcpy.S , it automatically switches to a sse2/avx2/evex implementation if those ISA extensions are present. It looks like the Linux kernel's memcpy does not attempt to use V at all neither (as of 6.9 arch/riscv/lib/memcpy.S),
- rwmj 2y ago
  > I had a quick glance at the glibc source code and didn't find anything other than a C implementation - do you know if that's a recent innovation or what version of glibc supports that? Or is any V implementation in glibc's string functions just relying on the compiler autovectorization (does that exist for RVV)? Or is this not upstream yet? Last I heard the glibc developers are waiting for a decent hardware platform to target. You need something that supports V1.0, is widely available, and performs something like we expect future hardware to perform so you don't end up optimizing for the wrong things. (Qemu is no use because the performance of emulated V is very different from the real thing since every V instruction goes through a TCG helper function.)
- brucehoult 2y ago
  > GCC refused to upstream support for RVV 0.7 until now IMHO the GCC people were being dumb. They don't want to upstream support for "draft" specs. That's fundamentally because it will be obsolete as soon as there's a new draft. But that should go out the window as soon as someone makes commercial hardware using that spec -- at that point it's frozen and those real-world users have a right to expect hardware they paid for to be supported. There was also the qustion of who will do the work, and THead and Allwinner and other interested parties in China were not quick to step up to do it. > I didn't realize common libc functions could be made binary compatible between RVV 0.7 and 1.0 Sure. For example here is something I posted in April 2021, tested on a prototype AWOL Nezha D1 board I got ssh access to in China a few months before customers started to receive them in late June / early July. https://hoult.org/d1_memcpy.txt https://hoult.org/d1_memcpy.txt Of course RVV 1.0 was not final then. But it turns out that if you change the `vlb.v` instruction to `vlbu.v` (which doesn't change the functionality as it's loading bytes in RAM to bytes in a vector register) then that maps to `vle8.v` in RVV 1.0. All the other instructions used are binary compatible with the equivalent RVV 1.0 instruction.