Project

General

Profile

Actions

GraphicsReplicant11 » History » Revision 18

« Previous | Revision 18/114 (diff) | Next »
dl lud, 09/02/2019 07:24 PM
SwiftShader: drm_hwcomposer task.


Graphics on Replicant 9

This page documents the current progress and future plans for the graphics acceleration on Replicant 9. The original plan can be found at TasksFunding. Since then, through more in depth research and hands-on experience, several things have diverged.

Background information, as well as details on the software components and acronyms used on this document, can be found at GraphicsResearch.

Graphics stack tasks

status origin short description notes estimated man-hours actual man-hours
done original plan Set up the development environment. Required: i9305 phones, LXC Trisquel container (systemd nspawn fails due to old systemd on Trisquel 8), larger SSDs, 1.8V serial-USB adapters (BS101P FT232RL) plus makeshift resistors' banks. 24 24
ongoing original plan Read graphics related AOSP documentation. Never-ending task that, besides actual documentation, involves scouring through source-code, bug trackers, mailing lists and IRC logs. 16 40
ongoing new Ask for help. Bothering free-software developers1 that have experience with or contribute to graphics sub-systems has been the most fruitful way to clear most roadblocks. 0 0
done original plan Use Mesa's llvmpipe backend instead of softpipe. Merge requests on Mesa: !1402 and !1403. There was no need to update LLVM version. 40 28
ongoing new Use Mesa's kms_swrast driver with drm/exynos. Solved with a simple hack.
TODO: make it more generic and send upstream.
Perhaps have the if clause read a list of additional drivers that would be supplied at compile time.
0 4
todo original plan Implement the missing pixel formats in drm/exynos. 72 0
todo new Get entire stack to use RGB555 pixel format. Had a huge performance boost on Replicant 6. 0 0
ongoing original plan Proper way to use DRM-Master and DRM-Auth with gbm_gralloc and drm_hwcomposer. Tried:
1. Auth hack (both on /dev/dri/card0)
2. vGEM (gbm gralloc on /dev/dri/card1) - Requires memory sync between vGEM and exynos. gbm gralloc cannot take advantage of exynos hardware planes.
3. Allow dumb buffers on render node (gbm gralloc on /dev/dri/renderD128) - Dumb buffers are used for scanout. Should not be created on a render node.
 
Correct solution is using DRM Magic and have both on /dev/dri/card0.
40 4
ongoing new Use hardware planes for better composer performance. Enabling HW planes with drm_hwcomposer was straightforward but led to severe graphics corruption.
Disabling devfreq fixed the corruption. Tentative explanation: display controller frequency gets too low for timely DMA transfer of overlays.
Reported upstream. TODO: lock display controller frequencies through sysfs and re-enable devfreq.
0 16
ongoing new Use Skia instead of HWUI to render the Canvas. Unlike Replicant 6, none of the usual system props (e.g. ro.kernel.qemu=1, ro.config.avoid gfx accel=1) would yield the expected performance.
Got there by forcing hardwareAccelerated=false on all apps.
TODO: turn this dirty hack into a system property that can be toggled on the device tree.
0 22
ongoing original plan Create test scenarios and check if the graphics stack works as expected. Testing has been done manually with the default apps. TODO: use apps that specifically require GLES 2.0 (e.g. Firefox-based browsers). 40 10
abandoned original plan Make the graphics stack work with vGEM driver besides drm/exynos. No need. All Replicant targets have a display and, likely, a companion display controller with a fitting drm driver too. Most drm drivers expose a render node that Mesa can use. Better use that instead of vGEM. 40 0
ongoing original plan Document the design decisions. Done at this wiki page plus the presentation at ContributorsMeetingJuly2019. 16 58

1 A big thanks to Joonas Kylmälä, Paul Kocialkowski, Andrés Domínguez, Denis Carikli, Mauro Rossi, Emil Velikov, Andrzej Hajda, Marek Szyprowski and LiquidAcid.

SwiftShader tasks

status origin short description notes estimated man-hours actual man-hours
done original plan Find a way to use SwiftShader instead of Mesa. Joonas got there with ranchu composer (from Android Emulator) and the default gralloc, plus a patch to support UDIV/SDIV emulation in the kernel. 40 0
done new Use LLVM as backend instead of SubZero. Found a SwiftShader revision that uses LLVM and is still compatible with Android 9 frameworks/native. No noticeable performance difference. 0 6
todo new Use drm_hwcomposer instead of ranchu. Advantages: uses hardware planes and DRM nodes instead of direct framebuffer. 0 0

Updated by dl lud over 4 years ago · 18 revisions

Also available in: PDF HTML TXT