3 ms·

That is definitely unfortunate given that I understand the 0.7.1 pre-standard seems to have been shipped very widely, it seems a bad decision for LLVM not to at

That is definitely unfortunate given that I understand the 0.7.1 pre-standard seems to have been shipped very widely, it seems a bad decision for LLVM not to at least provide an option to use intrinsics from that. That said my code as it is right now isn't doing a lot of array/vector type operations. There are likely places where some of my datastructures could be optimized to do so, but not right now. I'm most interested in just taking advantage of high parallelism on the 64 cores. We shall see how that works out.

crest 3y ago
It wasn't supposed to happen like this. The burden to support the 0.7.1 should be on those that pushed it into general availability instead of expected the rest of community to develop a code generator + optimiser for an overcome draft and maintain package repos etc. targeting only one vendors CPU core.
- cmrdporcupine 3y ago
  That is fair. Hopefully the # of pre-1.0 V units out there gets dwarfed quickly by a wave of new machines in the next couple years. Do you happen to know if the Pioneer board's CPU is socketed? I can't tell from the pictures, but it seems like might just be soldered on, which is a bummer. Because the hope would be that it could be upgraded later if/when SOPHON brings out a new chip, but I suspect that isn't going to be possible.
  - brucehoult 3y ago
    It's soldered. Socketed is a lot more expensive. There's also no point as the SoC is worth vastly more than the motherboard, so you'd probably pay 80% as much for a new CPU as for a new motherboard with CPU. The RAM is socketed, so you can reuse that.
- brucehoult 3y ago
  Agreed that THead and/or their customers should have been much faster off the mark with toolchain support (they're doing it now), but there is another equally vital aspect -- the upstream software maintainers have to agree in principle to accept patches. This agreement has been either withheld or else slow to come, with such weak reasons as "we don't support draft specs", intended to mean "specs that are never implemented in hardware". Mass production of chips with a "draft spec" make it not a draft at all in this sense -- it's effectively a custom extension, which patches SHOULD be accepted for. It's just a custom extension that happens to be 95% source code and binary compatible with the official extension.
- NewJazz 3y ago
  To be fair, THead released the cores as open source cores. Firms then just picked them up and put them in their SoC AIUI.
  - brucehoult 3y ago
    Absolutely not. For a start, every SoC containing a C906 or C910 core has at least one core implementing the V extension. THead's V extension implementations are optional (and extra cost) and are not part of the open-sourced cores on github.
    - NewJazz 3y ago
      Oh. Didn't know they were an add-on with additional cost. That is interesting.
snvzz 3y ago
>I understand the 0.7.1 pre-standard seems to have been shipped very widely Hardware, yes. Note it will still run non-vector code fine. Software, not at all. e.g. there's no public builds of Linux distributions targeting 0.7.1, not even unofficial. It is not even easy to get working under Linux, although René Rebe managed to[0]. 0. https://www.youtube.com/watch?v=trgEUBN_36M https://www.youtube.com/watch?v=trgEUBN_36M
- brucehoult 3y ago
  I find it amusing that René is known for two hacks: - enabling RDNA2-based Radeon GPU cards to work. The hack: saving and restoring FPU state in the kernel so that the kernel (more precisely: the GPU driver) can use floating point instructions. - enabling the use of RVV instructions on a standard Linux distro. The hack: primarily saving and restoring the Vector state in the kernel. It's essentially the same hack. I note also that the OS images recommended by the SBC vendors already have the Vector extension enabled e.g. the OS preinstalled on the Lichee Pi 4A, or Tina for the Nezha (and other D1 boards). The patches to do so are readily available. It's no big trick to apply them to upstream kernel sources, the problem is getting the result of doing so upstreamed.

crest 3y ago

It wasn't supposed to happen like this. The burden to support the 0.7.1 should be on those that pushed it into general availability instead of expected the rest of community to develop a code generator + optimiser for an overcome draft and maintain package repos etc. targeting only one vendors CPU core.

cmrdporcupine 3y ago
That is fair. Hopefully the # of pre-1.0 V units out there gets dwarfed quickly by a wave of new machines in the next couple years. Do you happen to know if the Pioneer board's CPU is socketed? I can't tell from the pictures, but it seems like might just be soldered on, which is a bummer. Because the hope would be that it could be upgraded later if/when SOPHON brings out a new chip, but I suspect that isn't going to be possible.
- brucehoult 3y ago
  It's soldered. Socketed is a lot more expensive. There's also no point as the SoC is worth vastly more than the motherboard, so you'd probably pay 80% as much for a new CPU as for a new motherboard with CPU. The RAM is socketed, so you can reuse that.
brucehoult 3y ago
Agreed that THead and/or their customers should have been much faster off the mark with toolchain support (they're doing it now), but there is another equally vital aspect -- the upstream software maintainers have to agree in principle to accept patches. This agreement has been either withheld or else slow to come, with such weak reasons as "we don't support draft specs", intended to mean "specs that are never implemented in hardware". Mass production of chips with a "draft spec" make it not a draft at all in this sense -- it's effectively a custom extension, which patches SHOULD be accepted for. It's just a custom extension that happens to be 95% source code and binary compatible with the official extension.
NewJazz 3y ago
To be fair, THead released the cores as open source cores. Firms then just picked them up and put them in their SoC AIUI.
- brucehoult 3y ago
  Absolutely not. For a start, every SoC containing a C906 or C910 core has at least one core implementing the V extension. THead's V extension implementations are optional (and extra cost) and are not part of the open-sourced cores on github.
  - NewJazz 3y ago
    Oh. Didn't know they were an add-on with additional cost. That is interesting.

snvzz 3y ago

>I understand the 0.7.1 pre-standard seems to have been shipped very widely Hardware, yes. Note it will still run non-vector code fine. Software, not at all. e.g. there's no public builds of Linux distributions targeting 0.7.1, not even unofficial. It is not even easy to get working under Linux, although René Rebe managed to[0]. 0. https://www.youtube.com/watch?v=trgEUBN_36M https://www.youtube.com/watch?v=trgEUBN_36M

brucehoult 3y ago
I find it amusing that René is known for two hacks: - enabling RDNA2-based Radeon GPU cards to work. The hack: saving and restoring FPU state in the kernel so that the kernel (more precisely: the GPU driver) can use floating point instructions. - enabling the use of RVV instructions on a standard Linux distro. The hack: primarily saving and restoring the Vector state in the kernel. It's essentially the same hack. I note also that the OS images recommended by the SBC vendors already have the Vector extension enabled e.g. the OS preinstalled on the Lichee Pi 4A, or Tina for the Nezha (and other D1 boards). The patches to do so are readily available. It's no big trick to apply them to upstream kernel sources, the problem is getting the result of doing so upstreamed.