blob: 1d7fcc02f55cdb848363be1fc8f7ccfd08294611 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
tags: Replicant news, Joonas Kylmälä
date: 2019-07-21T21:42:05+00:00
title: Graphics support for Replicant 9
authors: Joonas Kylmälä
---
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][1]. 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][2].
[1]: <https://lkml.org/lkml/2018/8/1/525>
[2]: <https://lists.osuosl.org/mailman/listinfo/replicant>
|
