I wonder how the driver situation is. From Jeff Geerling's work on running "big" GPUs on Raspberry Pis, my impression is that often less-common platforms should work but are littered with papercuts in practice.
AMD GPUs have worked on RISC-V for a couple years at this point. I have a Milk-V Titan that's paired with an AMD GPU running well: https://milkv.io/titan
…and when it comes to the most common use of big-iron GPUs right now, neural network engines, they're all so poorly put together that a papercut is often fatal. If every dependency isn't the exact needed version, the whole thing will collapse, and using all but the most common hardware is sure to be unsupported in some deprecated library version that is absolutely required to get everything running.
I had thought Xilinx ISE and Altera Quartus had the market cornered on the most difficult environments to get running, but then LLMs and stable diffusion came along.
You haven’t lived until you have done a model training run where different stages require mutually incompatible nvidia driver revisions and everything on top.
I had thought Xilinx ISE and Altera Quartus had the market cornered on the most difficult environments to get running, …
These tools were the reason why I gave up on FPGAs years ago and chose to spend my time on GPUs instead. And to this day, I still don't understand why they worked so differently from what I had expected in so many ways.
I highly recommend getting a small, cheap FPGA development board with something supported by Yosys, like a Latice ICE40UP5k, Efinix T8F81C2, or GOWIN GW1NR-9.
Yosys is a super lightweight open-source FPGA toolchain that really easy to get up and running. The FPGA models I mentioned have ~5k to ~10k LUTs, can all support simple RISC-V processors, and have built-in memory and DSPs.
lean from a technical point of view: size and complexity. That would include the SDK, namely the complexity of the syntax of used computer language (for instance excluding de facto c++ and similar), the build system, the amount of dependencies, etc.
Somehow the RISC-V designs mostly seem to have more coherent PCIe implementations, meaning some devices are easier to get running without the arm64 quirks drivers have to work around.
Drivers still need tweaking, most of the time, since most are still built assuming an amd64 world.
Comments
I wonder how the driver situation is. From Jeff Geerling's work on running "big" GPUs on Raspberry Pis, my impression is that often less-common platforms should work but are littered with papercuts in practice.
AMD GPUs have worked on RISC-V for a couple years at this point. I have a Milk-V Titan that's paired with an AMD GPU running well: https://milkv.io/titan
Maybe a Zen microarchitecture with a RISC-V/RVA front-end?
While thinking about it, if NVIDIA or SAMSUNG go performant RISC-V CPU micro-architecture, will "probably" change the world.
…and when it comes to the most common use of big-iron GPUs right now, neural network engines, they're all so poorly put together that a papercut is often fatal. If every dependency isn't the exact needed version, the whole thing will collapse, and using all but the most common hardware is sure to be unsupported in some deprecated library version that is absolutely required to get everything running.
I had thought Xilinx ISE and Altera Quartus had the market cornered on the most difficult environments to get running, but then LLMs and stable diffusion came along.
You haven’t lived until you have done a model training run where different stages require mutually incompatible nvidia driver revisions and everything on top.
These tools were the reason why I gave up on FPGAs years ago and chose to spend my time on GPUs instead. And to this day, I still don't understand why they worked so differently from what I had expected in so many ways.
I highly recommend getting a small, cheap FPGA development board with something supported by Yosys, like a Latice ICE40UP5k, Efinix T8F81C2, or GOWIN GW1NR-9.
Yosys is a super lightweight open-source FPGA toolchain that really easy to get up and running. The FPGA models I mentioned have ~5k to ~10k LUTs, can all support simple RISC-V processors, and have built-in memory and DSPs.
That's why _LEAN_ open source is really required, and that includes the SDK.
What does "LEAN" mean in this context? (I'm not familiar and 10 seconds of duckduckgo didn't answer)
lean from a technical point of view: size and complexity. That would include the SDK, namely the complexity of the syntax of used computer language (for instance excluding de facto c++ and similar), the build system, the amount of dependencies, etc.
Somehow the RISC-V designs mostly seem to have more coherent PCIe implementations, meaning some devices are easier to get running without the arm64 quirks drivers have to work around.
Drivers still need tweaking, most of the time, since most are still built assuming an amd64 world.
oh a double wide surprise for the AI industry? just what we needed.