Graphics support for Replicant 9

Thanks to volunteer effort and NLnet funding we have had developers working hard the past couple weeks on making graphics work on the Samsung Galaxy S3 for the upcoming Replicant 9 release. Three different software renderers have been successfully used with the current Replicant 9 development version: softpipe (Mesa), llvmpipe (Mesa), and SwiftShader.

The Linux kernel and Mesa required some small tweaks to allow using the Exynos DRM driver for software rendering. For the Linux kernel we had to allow in the DRM subsystem the creation of dumb buffers for render nodes as discussed previously on LKML. The devfreq module was also disabled as a workaround for graphics corruption issue that happened due to too low clock speeds. Mesa on the other hand required us to whitelist Exynos DRM driver to be used with a software rendering driver called kms_swrast. After these tiny changes we were already able to use the Mesa’s software rendering backend called softpipe! Unfortunately, softpipe turned out to be unusably slow even after using HW overlay planes to offload some of the buffer compositions to the Exynos 4412 display controller found on the Samsung Galaxy S3.

Next the community members Putti, dllud and GrimKriegor worked on a new revision for a patch originally used in the Android-x86 project for enabling llvmpipe support in Mesa. When the compilation fixes and slight adjustments for the rebased original patch were done we had yet another software renderer to use. The new revision of the patch enabling llvmpipe is now submitted again to Mesa and hopefully this time around it will go through.

The rendering speed with llvmpipe turned out to be only slightly faster than softpipe and still unusable for everyday usage. There are plans optimize llvmpipe for the ARM Cortex-A9 processor in Exynos 4412 so hopefully soon it will be usable for everyday usage.

Before diving into the world of NEON optimization for llvmpipe and so forth, we decided to give SwiftShader software renderer a go together with hwcomposer.ranchu and gralloc.default. Other than having to add support for UDIV and SDIV instruction emulation in the Linux kernel, we got it running by simply setting some system properties and adding the SwiftShader and hwcomposer.ranchu modules to the system image. The speed of SwiftShader felt like it was at least twice as fast compared to llvmpipe and softpipe but still just a tiny bit too slow to be enjoyable for everyday usage. We are now hoping to find people that could work with us to replace hwcomposer.ranchu with drm_hwcomposer. Using drm_hwcomposer with SwiftShader would allow us to take advantage of HW overlay planes to speed up the compositions.

If you are interested in helping or want to learn more you can get in touch with us on IRC on the #replicant channel on Freenode, or via our mailing list.