- cross-posted to:
- technology@lemmy.ml
- cross-posted to:
- technology@lemmy.ml
You must log in or register to comment.
I love the idea of risc-v. Good luck to these people.
I don’t think Steam and Wine works on RISC-V? Especially if Wine uses native x86 instructions.
But maybe in the future games will be recompiled for RISC-V, wouldn’t be surprised if it ends up being a checkbox on Godot.
Steam for Linux only has x86 builds right now and wine only translates system calls, so by default they won’t work.
There are ways to get them to work though, but they mostly involve emulating x86. Given the performance of the current state of the art in RISC-V, that won’t exactly go well right now.
That said, that’s not what this machine is for at all. As a software developer working on developer tools for Linux, this is particularly interesting to me as a way to improve the Linux RISC-V ecosystem while dogfooding my own stuff.
WINE Is Not an Emulator and there is no Windows on RISC-V.
wouldn’t be surprised if it ends up being a checkbox on Godot.
one of the reasons I love Godot :D
In terms of specifications all I can find is that this has a 2.0GHz 8-core RV64 processor with Vector. That’s not a lot of info.
Does anybody know anything more about it? Performance level, battery life, etc. I expect this is really a phone or SBC level processor, so it should sip power, right?
Do not expect this thing to be a daily driver. It’s aimed at developers who need a Risc-V testing platform. Very few Software will run on it unless you can spend hours making it compile for Risk-V and lets not talk about drivers. Also it will likely cost over $1000.
I am exited for the future of Risc-V in the consumer space, but we aren’t there yet.
Ok that makes more sense… The price point didn’t match the specs for a consumer product
deleted by creator
let’s* not talk about
Performance level
Not good. That bench is from a BananaPi with the same SoC, via reddit (sorry).
Maybe about an A55. If you want a performant RISC-V you’ve gotta wait until stuff leaks out of the European Supercomputer stuff onto the market though that one probably won’t have good IPC either unless it’s vector, or maybe one of the big chip design companies will grace us with a chip with a RISC-V insn decoder.
I think those will have to have fairly good IPC, otherwise they won’t be able to keep the array processors fed with work.
Guess we’ll see.
You can keep the array processors fed with low IPC and frequency by having absolutely massive vector lengths, the engineering for that kind of processor isn’t in the pipeline, branch prediction etc. it’s in the APUs and how to stream data into them. Much more like GPUs, in fact RISC-V has instructions for gather/scatter.
Disagree. You quite often have a fair degree of scaler code in between portions which are embarrassingly parallel. If you don’t have a decent scaler core you are destined to be become bottlenecked on them. It’s not that different to a CPU / GPU pairing. If one is under powered, it determines the speed of the overall system.
If you look at what a company like Tenstorrent is doing, they are designing high performance Risc-V cores as a side aspect of their main goal of doing array processors. The reason is because they couldn’t find scaler cores on the market with enough performance to not bottleneck the system.
If they do something like a NUC form factor, I might buy it. I think it would make a decent NAS, but not a great laptop/desktop due to missing software. If it has solid USB-C, I can get a HDD enclosure and be good to go with RISC-V.
It performs worse than Raspberry Pi 3.
What if you compile the missing software from source?
A lot of software people use on desktop is proprietary and not source available. There is also no guarantee open source stuff is portable.
Most FLOSS stuff will compile without issue. Practically all the portability issues got sorted out when x86_64 became a thing, stuff gets regularly build for arm32 and arm64, and basically all inline assembly has alternative generic code paths which actually won’t be that bad because it’s way easier for compilers to output good vector code than it is to output good SIMD code, less room for hand-optimisation.
Once the kernel and drivers are up and running you’re good to go because the vast, vast, vast majority of code doesn’t care a bit about what CPU it is running on.
Laptop form factor is very ambitious! Huge respect. I would love to give one a spin
