So I'm unfamiliar with this so let me ask a few dumb questions but first of all great job! My questions are - If you didn't do this work how would you use this soc? When I search, it is stated that it supports OpenGL and Vulkan but was that just ' in theory? ' How can a SOC developer make a product without driver support? Don't they risk messing up and having hardware that doesn't work properly?
You see they don't care. They give you a OS image on Google Drive with a forked kernel and call it a day.
Silicon hardware companies have one of the dumbest business models, when it comes to programmable chips. They want to sell chips, because it makes them money through sales. They don't want to spend money on software support, because you cannot link the software to a sale. So software to them costs money and produces no benefits.
But when you think about it even a little bit, you start to wonder. Who is going to write commercial grade software for a commercial hardware product that they don't make money off? Nobody. What you'll get is an anemic volunteer effort at best. The volunteers might even do a good job, but since they are not involved in the hardware development process, they will always be playing catch up and take a year until the latest hardware is supported. So even in the theoretical best case scenario the hardware will be sold when it is least attractive.
This business model is completely illogical and Nvidia doesn't follow it. Instead Nvidia proactively invested in a software ecosystem for their hardware, thereby leading them to their current valuation.
The same applies to Intel and x86. People prefer x86 boxes, because the software ecosystem of drivers, UEFI/booting and so on is fully mature, whereas ARM SBCs are a fragmented mess.
The GPU driver itself is largely the same, though it might need some tweaks for the specific variant in the K1.
The bigger hurdle will likely be the display controller. The TH1520 and JH7110 both use the Verisilicon DC8200, whereas the Spacemit K1 uses a custom display controller that will need its own DRM driver mainlined.
The Orange Pi RV2 (Ky X1) uses the Imagination BXE-2-32.
The good news is that firmware is available for that variant. The bad news is that Mesa currently lists the BXE-2-32 as 'unsupported / not under active development' (unlike the BXS-4-64 in the TH1520, which is active).
https://docs.mesa3d.org/drivers/powervr.html
So while the kernel driver (drm/imagination) is the right path, the RV2 is a steeper hill to climb: it needs the SoC kernel plumbing and likely some work in Mesa.
I agree DisplayPort would be nice, but unfortunately, almost all currently available RISC-V SBCs only have physical HDMI and MIPI DSI connectors. We have to support the hardware that actually exists on the board.
Thanks so much for great work! I hope to finally see VisionFive 2 with enabled GPU acceleration soon.
So I'm unfamiliar with this so let me ask a few dumb questions but first of all great job! My questions are - If you didn't do this work how would you use this soc? When I search, it is stated that it supports OpenGL and Vulkan but was that just ' in theory? ' How can a SOC developer make a product without driver support? Don't they risk messing up and having hardware that doesn't work properly?
You see they don't care. They give you a OS image on Google Drive with a forked kernel and call it a day.
Silicon hardware companies have one of the dumbest business models, when it comes to programmable chips. They want to sell chips, because it makes them money through sales. They don't want to spend money on software support, because you cannot link the software to a sale. So software to them costs money and produces no benefits.
But when you think about it even a little bit, you start to wonder. Who is going to write commercial grade software for a commercial hardware product that they don't make money off? Nobody. What you'll get is an anemic volunteer effort at best. The volunteers might even do a good job, but since they are not involved in the hardware development process, they will always be playing catch up and take a year until the latest hardware is supported. So even in the theoretical best case scenario the hardware will be sold when it is least attractive.
This business model is completely illogical and Nvidia doesn't follow it. Instead Nvidia proactively invested in a software ecosystem for their hardware, thereby leading them to their current valuation.
The same applies to Intel and x86. People prefer x86 boxes, because the software ecosystem of drivers, UEFI/booting and so on is fully mature, whereas ARM SBCs are a fragmented mess.
man, things haven't changed since the nineties... What you said about Nvidia is 100% facts
Nice! Looking forward to finally getting proper support for my Lichee Pi 4A!
Hooray! Personally, I'm hoping this'll lead to support for the GPU on Spacemit SoCs.
The GPU driver itself is largely the same, though it might need some tweaks for the specific variant in the K1.
The bigger hurdle will likely be the display controller. The TH1520 and JH7110 both use the Verisilicon DC8200, whereas the Spacemit K1 uses a custom display controller that will need its own DRM driver mainlined.
Kudos, great project, i wait to have my work machine being the RISC-V once...
Fantastic, good work. I'm looking forward to mainstream RISC-V.
Congratulations!
BTW is OrangePI V2 supported?
The Orange Pi RV2 (Ky X1) uses the Imagination BXE-2-32.
The good news is that firmware is available for that variant. The bad news is that Mesa currently lists the BXE-2-32 as 'unsupported / not under active development' (unlike the BXS-4-64 in the TH1520, which is active). https://docs.mesa3d.org/drivers/powervr.html
So while the kernel driver (drm/imagination) is the right path, the RV2 is a steeper hill to climb: it needs the SoC kernel plumbing and likely some work in Mesa.
Ouch!!!
I will have to wait then. I may choose a supported variant then.
This year will see the first chips with RVA23 support.
K3 (which succeeds K1 this story is about) is expected to be among them.
Yay!!!
what's the point of supporting HDMI?
just let this worse standard die already - and switch to DisplayPort
I agree DisplayPort would be nice, but unfortunately, almost all currently available RISC-V SBCs only have physical HDMI and MIPI DSI connectors. We have to support the hardware that actually exists on the board.
If your board comes with a HDMI output you surely want to the that to connect e.g. a TV