It exists (i’ve had versions for some time) but it’s not from Amlogic and it’s not clearly redistributable. The holy grail to make single-image nirvabna possible is the T820 blob. The alternative route is to support VIM1/VIM3 and RK devices with blobs, and VIM2 with panfrost. I’m not aware of the Panfrost developers doing any work on Bifrost yet - but their stated goal is to get Midgard support into a solid state before they think about expanding coverage so that’s expected.Īpplications like Kodi are linked against libgbm which is provided differently for kbase+blob and kernel+mesa hence why LE needs two separate Amlogic images for GX (using the FOSS drivers in the kernel) and G12 devices (using kbase/blobs). There is no support for Bifrost GPUs at this time (G31/G52 etc.) although the panfrost kernel driver has some device ID placeholders so it might claim to see the chip, but that’s all it can do. Panfrost supports Midgard GPUs … Amlogic uses T820 and RK uses T760/T860. Lima supports Utgard GPUs only … Mali 400/450/470. So in LE we package a kernel defconfig with both lima/panfrost enabled to support GX hardware and then sed/disable the modules in the defconfig at build-time if the target device is G12. NB: On the kernel side the panfrost driver will match a bifrost device-tree node and load, which will interfere with the mali_kbase driver. There is currently no mesa userspace support for bifrost so it’s not an option for VIM3. The T820 in the VIM2 is less well tested compared to the T860 but works fine for Kodi - I can’t speak for wider desktop use. Panfrost for T860 doesn’t require anything more than CONFIG_DRM_PANFROST=m with any 5.4-rc kernel but for userspace it’s best to track mesa master as development continues at pace. I may also skip 5.4 and go directly to 5.5-rc kernels in order to reduce the patch count I’m working with. I’m also submerged in a work project at the moment so I haven’t had time to do much experimenting to self-answer questions, so I’m kind of waiting for 5.4 to ship and hopefully a clearer path to emerge. The current challenge is that Maxime is MIA for personal reasons, so i’m not getting answers to questions and the userspace rework should really start with the updated kernel vdec code and firmware.
On the ffmpeg side the existing stateful support is also outdated and needs rework to handle the revised vdec code. The upstream firmware set also needs revision and has some known issues.
It’s not clear to me if other codecs (not yet submitted to the list but available if you know where to look) also need rework or can be used as-is. Upstream APIs have evolved since the original work that Maxime did and this necessitates rework, hence the two commits submitted to the linux-amlogic mailing list in October to resolve some API compliance issues and add H264 support. The vdec commits are in limbo at the moment.
0 kommentar(er)
