[Replicant] [hardware_ti_omap4] [PATCH] Workaround slow llvmpipe

Denis 'GNUtoo' Carikli GNUtoo at cyberdimension.org
Mon Dec 7 19:25:14 UTC 2020


At first all the devices were using libagl. The issue is that
certain applications like browsers based on Gecko didn't work
as the OpenGL implementation wasn't complete enough.

Then all devices were switched to llvmpipe, however the OMAP4
devices had a black screen at boot.

Some attempts were made to enable specific devices to override
the OpenGL implementation without much success. Since that
didn't work, it would probably have required to move the
OpenGL implementation in devices or common devices repositories
and require changes in too much repositories.

To avoid that, the following commit was made in framework/native
to rid of the black screen of the OMAP4 devices at boot:
    108a3f6c45c354116578f2d4bf6979c3b8aa0fb8
    108a3f6c4 Enable llvmpipe on the Samsung devices with an OMAP4 SOC

The real effect of that commit was to disable the ti_hwc and make
the devices fall back on the default implementation which worked
with llvmpipe.

The issue is that, with that change, for some reasons graphics
were painfully slow: On the Galaxy Tab 2, and the Galaxy Nexus,
there was barely enough speed to enable users to go in the
settings, enable root, and run a shell script to activate back the
old libagl implementation.

I then tried to force EGL_SLOW_CONFIG but it didn't work anymore
with the default implementation as it failed to be selected.
This made me conclude that the correct solution was probably to
enable ti_hwc to use llvmpipe somehow.

As this probably requires more work, and that work is ongoing to
make Replicant use a kernel closely based on upstream Linux, it
makes more sense for me to find a quick workaround here to have
more time to work on Replicant versions that will have a kernel
closely based on upstream Linux.

This workaround was found in device/generic/qemu/ in
init.ranchu.rc:
    # Disable GPU support
        setprop ro.kernel.qemu 1
        setprop ro.kernel.qemu.gles 0

It appears to disable OpenGL somehow as running the tor-browser 10.0.5
resulted in the tor-browser crashing when clicking on the URL bar,
and the following log:
    I Gecko   : Can't find symbol 'eglGetNativeClientBufferANDROID'.
    I Gecko   : Can't find symbol 'eglQuerySurfacePointerANGLE'.
    I Gecko   : Can't find symbol 'eglDupNativeFenceFDANDROID'.
    I Gecko   : Can't find symbol 'eglQueryDisplayAttribEXT'.
    I Gecko   : Can't find symbol 'eglQueryDeviceAttribEXT'.
    I Gecko   : Can't find symbol 'eglStreamConsumerGLTextureExternalAttribsNV'.
    I Gecko   : Can't find symbol 'eglCreateStreamProducerD3DTextureANGLE'.
    I Gecko   : Can't find symbol 'eglStreamPostD3DTextureANGLE'.
    I Gecko   : Can't find symbol 'eglSwapBuffersWithDamageEXT'.

However the graphics speed is now similar to the speed we had with libagl.
So it is probably similar to reverting to libagl, without having to modify
too much repositories.

There is also some more background information on that bug in
the Replicant bugtracker[1][2].

[1]https://redmine.replicant.us/issues/2171
[2]https://redmine.replicant.us/issues/1994

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo at cyberdimension.org>
---
 rootdir/init.omap4.rc | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/rootdir/init.omap4.rc b/rootdir/init.omap4.rc
index 686a3d1..c9d0e9e 100644
--- a/rootdir/init.omap4.rc
+++ b/rootdir/init.omap4.rc
@@ -7,6 +7,12 @@ on boot
     restorecon /sys/devices/platform/omapdss/manager0/cpr_coef
     restorecon /sys/devices/platform/omapdss/manager0/cpr_enable
 
+# Workaround slow llvmpipe at the expense of applications
+# compatibility. While this defeats the point of using llvmpipe
+# it enables all the devices (exynos and OMAP) to use llvmpipe.
+    setprop ro.kernel.qemu 1
+    setprop ro.kernel.qemu.gles 0
+
 on fs
     # Load PVR module
     insmod /system/lib/modules/pvrsrvkm.ko
-- 
2.29.2



More information about the Replicant mailing list