Collabora has just announced that the Panthor open-source GPU kernel driver for third-generation Arm Valhall GPUs (Arm Mali-G310, Mali-G510, Mali-G610, and Mali-G710) has now achieved OpenGL ES 3.1 conformance with the Arm Mali-G610 GPU found in the Rockchip RK3588 SoC.
Just a few days ago, Linux 6.10 was released with “support for Mali CSF-based GPUs found on recent Arm SoCs from Rockchip or Mediatek”, as expected from the earlier article entitled “Panthor open-source driver for Arm Mali-G310, Mali-G510, Mali-G610, and Mali-G710 GPUs to be part of Linux 6.10” published last March. But this did not say anything about the level of support for the Valhall GPU since it’s common for new hardware to be added with minimal support, and OpenGL ES 3.1 compliance means it’s ready for business…
Collabora’s announcement explains this was tested on a Radxa Rock 5B single board computer:
The conformance tests ran on a Rock5b board under Linux 6.10.0-rc1. This version of Linux contains the new Panthor kernel driver for Mali v10 […] The RK3588 SoC used in the Rock5b is a popular chip for Arm-based single board computers. Having support for it upstream in both Mesa and the kernel means that Linux distributions can now easily support graphics acceleration on these devices.
So not only the kernel driver is now compliant, but the userspace driver has been upstreamed to Mesa (24.1.1), meaning 3D graphics acceleration will now work with fully open-source drivers on the Rockchip RK3588 SoC and other SoCs with Arm Valhall GPUs can be supported too. This follows Panfrost OpenGL ES 3.1 conformance with Mali-G57 GPU in 2022.
It’s another good software news for the Rockchip RK3588 SoC that recently got support for NPU-accelerated LLM, and is already usable with mainline Linux for some applications as shown in the Linux mainline matrix provided by Collabora, although admittedly there’s still some work to do for multimedia open-source drivers for the VPU (video decoder/encoder), MIPI DSI/CSI display and camera interfaces, and a few other drivers.
Collabora still plans to do more work on the Panfrost and Panthor drivers, notably:
- Support for performance counters to assist programmers in optimizing their graphics code
- Support for device coredump to assist in debugging firmware and driver issues
- Support for the new Arm AFRC compression format for frame buffers
- Improving memory management to allow better behavior in low-memory situations
- General performance improvements
- Vulkan support (this may take a while)
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Yay! Does that mean, LibreELEC has no more excuses ;)?
Aren’t you afraid of real *ELEC developers reading such statements?
Not excuses, reasons.
Only the other day, a question was asked on their forums about the possibility of a LibreELEC image for RK358.
The question posed was “With the new release of Linux 6.10 Release, notably the Panthor open-source driver now being an official constituent of the kernel, does this increase the possibility of official LibreELEC support?”
The answer from dev chewitt was “Yup! but AFAIK the codebase is still lacking HDMI audio and most of the video codecs”
He then cited a Collabra link to illustrate these points.
HDMI Audio, H.265 encoding and others are on the TODO list.
Which means that they are closer but not in a position to complete things based upon how things are, outside of their control, right now.
They do all this work for nothing of course and therefore, why should they put time and energy into things that have too many obstacles.
Look at how quickly a Rpi5 image was produced. This was because the required elements were present.
The whole RK3588 position is as it is because of Rockchip and associated manufacturers. All ire should be pointed squarely at them and quite correctly too.
RK3588 has been closer to becoming another successive lemon, like the RK3399 that never reached it’s potential in terms of software ability.
How would you even use it as a media center if there are not many VPU drivers for the mainline kernel? I think the only one that exists it av1 decode. It’s not the fault of anyone at LibreELEC.
x86 4eva
Since the likes of the N100 and N97 came along, it is hard to disagree in this specific comparison.
If Intel updates with Skymont E-cores, we’re potentially looking at a 40% IPC gain over Gracemont.
Unfortunately, we’re likely to get a Gracemont refresh first.
I think that Intel has one eye on a very uncertain future and hopefully it might spur them on to give more.
Bur then this is Intel, so logic is not the norm lol
The mesa ibrary was pushed in Debian Unstable sind around the end of may (21.1 with an 6.10-rc-kernel). Recently Mesa 21.1.3 hit Debian Trixie. I expect the 6.10-kernels to follow soon.
Are there any developers working on a opensource firmware replacement for these GPUs? Sadly you cant run them with just opensource software.
Still no android support? Why?