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.

3 thoughts on “Graphics support for Replicant 9

  1. That’s a good point, thanks for clarifying.
    Are there many phones with (near) mainline kernel? So far I always felt slightly depressed when discussion came to kernels re lineage support, even on newer devices…

    Would be great getting my P6800 past ICS.

  2. We are using Linux 5.2 with a few patches on top of it. In 5.2 the kernel got support for Lima so in theory we could try using it now. However, by having a fast software rendering working first we can release Replicant 9 in a shorter time frame for various devices instead of just Mali devices.

  3. Isn’t the S3 a Mali 400 device? Why not trying Lima? Or are we still stuck at a 3.10 Kernel? I guess targets like the upcoming pine phone are much more thankful targets for a project like replicant, as it would allow to distinguish yourself from other android efforts gluing newer and newer userlands to old kernels.

    In any case great news hearing replicant is working on an android 9 release.

    Thanks to all involved!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.