Embed Size (px)
Citation preview
GloDroidor boosting true open source Android stack development.
Roman Stratiienko, GlobalLogic Ukraine
1. Introduction2. Components selection3. Graphic buffer allocation4. Hardware composition5. Audio configuration6. Meson and Soong
1. IntroductionSupported Pending
Raspberry PI 4
Orange PI 4(Rockchip) Khadas VIM3
PineTabPinePhone
Orange PIs ( -PLUS-2E, -PC, -3 )
CLEAN AOSP v11rX (>700 repositories)
1. GloDroid device configuration repository2. Mainline mesa3d fork + 14 patches3. Mainline u-boot fork + 17 patches4. Mainline drm_hwcomposer fork + 1 patch5. Mainline gbm_fralloc fork + 3 patches6. Mainline tinyhal7. Mainline ATF
Kernel:8. Sunxi: integration branch from @megous mixed with Google kernel branch + 11 GloDroid patches9. Broadcom: Raspberry PI integration branch+ Google patches, 0 GloDroid patches.
+ Firmwares (6 repositories) + Linaro ARM compilers (3 repositories) + FOSS Applications repository (SkyTube, etc.)
Lina
ro V
irtua
l Con
nect
202
1
Intro
duct
ion
74f9609318082 Fix v3d linking errora438de834ddd0 android: mesa: Move the FXT1 compressor/decompressor to util/a4e3678d6ff0b android: egl: Implement EGL_KHR_swap_buffers_with_damage11556ea6af6ec Revert "lima: use linear layout for shared buffers ...40542e6feb7db HACK: Support for Android-Q68a80844dbf57 [RFC] v3d: Use v3d with vc4 for kmsro.6ac46e9c167ce vc4: Fix Android build24e38d311e8ac v3d: Enable Android build512464b287b54 egl: android: add gbm_gralloc and drm_gralloc support39b24cdeb1de6 egl: android: add IMapper@4 metadata API buffer_info getterb58d86a5385d7 egl: android: prepare code for adding more buffer_info getters3a02a003c4e68 egl: android: use num_planes param in createImageFromDmaBufs()fcf524e9866a4 frontend/dri: add AR12 and AR15 format supporta5d29cce84195 android: loader: convert Android.mk to Android.bp66fd9de6f5e81 ------------------------ mainline mesa3d --------------------7e77bfb68a9e4 ....
Current mesa3d “git log”
GloDroid components and mainlining status
Lina
ro V
irtua
l Con
nect
202
1
Intro
duct
ion
Lina
ro V
irtua
l Con
nect
202
1
Intro
duct
ion Project goals:
Goal #1. Bring-up 100% open-source Android that can be downloaded and compiled using few shell commands.Goal #2. Support most popular and accessible development platforms.Goal #3. Be as close as possible to the mainline, so our project can be easily integrated with other up-to-date mainline-friendly components.
Solutions:Solution for #1. Choose build system Option A (current): Extend AOSP build system by creating custom rules. Option B (may be the future): Create top-level build system (use yocto, etc.) and use AOSP as is.Solution for #2. Continuously do more research. Different SOCs vendors have unique boot flow and driver set, different hardware acceleration features., etc. Common things should be combined and only differences should be described.Solution for #3. Find the appropriate components already available, choose the most advanced and up-to-date from the list, always contribute our experience back to the mainline.
Top directives:Do not change AOSP system part. Create only temporary forks of AOSP vendor part (to test or while waiting up-streaming). Reuse as much as possible from Linux world (ARMBIAN scripts, etc.)
Lina
ro V
irtua
l Con
nect
202
1
Intro
duct
ion
Commercial world philosophies:1. All code should be kept proprietary, opening our work to the FOSS domain will reduce our advantages on the market.
2. Part of the code that isn’t at cutting edge of the technologies can be open-sourced. We won’t lose anything. Our competitors do have already these features. However, we can reduce our own effort by sharing our work with community. Instead we can invest freed up time into increasing our competitive advantages by doing more innovative stuff.
All above should be implemented considering constraints on available engineering resources for POCs in s/w service company (part-time assignments with low priority). Otherwise we are risking to slow down or completely stop.
Solution: Align the project with the company's interests: Leverage the POC for training/mentoring activities Start doing attempts to commercialize our work
Limitations:
2. Search for already available components
Lina
ro V
irtua
l Con
nect
202
1
Com
pone
nts
HAL
3. New vision for graphic buffer allocation
1. Simplified AOSP Gralloc API2. gbm_gralloc3. minigbm
Lina
ro V
irtua
l Con
nect
202
1
Gra
phic
buf
fer
allo
catio
n
Simplified AOSP Gralloc API
Lina
ro V
irtua
l Con
nect
202
1
Gra
phic
buf
fer
allo
catio
n
gbm_gralloc
Lina
ro V
irtua
l Con
nect
202
1
Gra
phic
buf
fer
allo
catio
n
minigbm
4. Our architecture proposal for hardware-accelerated graphic
compositor.
1. Simplified AOSP HWComposer2 API2. drm_hwcomposer project introduction3. Proposal for structural redesign4. Introduce component level planning5. Improve DRM-level planning6. Optimization
Lina
ro V
irtua
l Con
nect
202
1
HW
CO
MP
OS
ER
HWComposer2 API
Lina
ro V
irtua
l Con
nect
202
1
HW
CO
MP
OS
ER
drm_hwcomposer
GlobalLogic contributions since 2018:
1. Fixed misordered layer rendering.2. Force composition using GPU if UI isn't updating (flattening).3. Support GPU offloading for video buffers.4. Color space and range selection for video buffers.5. Fix scaled UI issue (for hi-res smart TVs).6. Fixed some of AOSP VTS tests.7. Ability to select primary display across multiple external displays.8. KMS device lookup feature.9. Add basic support for Imagination Grallocs buffer metadata extraction.10. Implemented algorithm that reduces load on the GPU by correctly choosing layer set to squash by GPU.11. First steps to reorganize project structure. (decouple Gralloc-specific buffer information converters from platform customization logic)
Not used by drm_hwc yet
Lina
ro V
irtua
l Con
nect
202
1
HW
CO
MP
OS
ER
drm_hwcomposer
Current TODO list:
1. Back-light controller API support.2. Make internal terminology and structure more intuitive, create structural diagram to help newcomers navigate the code.3. Extend architecture to support more types of compositors/converters (GLES, v4l2, writeback, etc.)4. Fix FPS rate drop on multiple displays by switching to asynchronous atomic commit.5. Use advanced algorithm for layer to plane mapping.6. Properly use shared KMS planes.7. Fix other reported issues. More....
Not used by drm_hwc yet
Proposal main goals:
1. Help newcomers to navigate the code.2. Ability to create automated test scenarios and share them with kernel-side driver maintainers as pure-linux application to report kernel issues.3. Add new compositors and other techniques to improve GPU-offloading efficiency.
Lina
ro V
irtua
l Con
nect
202
1
HW
CO
MP
OS
ER
drm_hwcomposer structural reorganization proposal
Lina
ro V
irtua
l Con
nect
202
1
HW
CO
MP
OS
ER
Lina
ro V
irtua
l Con
nect
202
1
HW
CO
MP
OS
ER
Lina
ro V
irtua
l Con
nect
202
1
HW
CO
MP
OS
ER
5. XML-based audio configuration
Lina
ro V
irtua
l Con
nect
202
1
Aud
io
conf
igur
atio
n
6. Meson to Soongbridge
1. Problem description2. Solution proposal
Lina
ro V
irtua
l Con
nect
202
1
Mes
on to
Soo
ngbr
idge
The problem:1. Internally AOSP aims to support only Soong build system. This does mean any external component must be soong-compatible and must contain Android.bp file.2. Currently AOSP can work with make-like (Android.mk) rules, but Google continuously restricts it and want to destage it some day.3. Both MESA3D and LIBCAMERA project was initially created for linux and uses meson build system.4. MESA3D project has set of Android.mks but it is not officially supported by maintainers and very soon became out-of-sync with Meson rules and require continuously fixing. Due to this out-of-sync nature, you can't build the project at every commit. You have to find working points or fix build manually. Bisect is almost impossible in this condition. In addition only limited set of drivers are available for build.5. Soong build system can't be used by the software that require pre-generation of some of its parts.
Solution #1 (Chromium OS way).- Build the project externally using Android-NDK and ship it as a binary blob.Pros: Already working for mesa3d and libcamera.Cons: Require external build system. Can not be embedded into AOSP. NDK has limited API, for example using Mapper metadata API to get buffer parameters isn't possible yet. Solution #2 (Linaro/AOSP way).- Manually adjust the rules, pre-generate required sources and put them together with original sources. Change Android.mk to use prebuilt sources. Pros: Mesa3d can be embedded into the AOSP in source code form.Cons: Each update require spending huge amount of work-hours. No bisect-ability and long upgrade cycle. Not mainline-friendly solution. Solution #3 (GloDroid way).- Add few hacks on top of mesa3d tree to overcome AOSP restrictions.Pros: Only small difference with mainline is required (just a few code lines).Cons: Having hacks is not best option. We are still relying on usually broken Android.mk.
Lina
ro V
irtua
l Con
nect
202
1
Mes
on to
Soo
ngbr
idge
1. In case top-level build system exists it can trigger regeneration, so it is not necessary to store the pre-generated part.
2. For pure-AOSP integration regeneration must be triggered manually, so it is important to store pre-generated output in the repository (better to create separate repository for that).
AcknowledgmentsGoogle for their awesome OS
Linaro and John Stultz for support
MESA3D and 3d-graphics experts:Alyssa Rosenzweig
Qiang YuVasily Khoruzhick
many other
FOSS Android HALs authors/contributorsRob Herring Sean Paul Richard Fitzgerald
many other
Chromium OS teamAndroid-x86 team
libcamera team
GlobalLogic and GloDroid team:Managing
Oleksiy Oguy Maryna SergiyenkoEngineering
Roman StratiienkoDaniil Petrov Roman KovalivskyiMatvii Zorin Maksym Prymierov
Aleksandr Bulyshchenko Design PR Mariia Herton Ellina Medynska
GloDroid external contributors:Sunxi platform contributor:
Icenowy ZhengAmlogic platform contributor:
Neil Armstrong Roman Stratiienko, GlobalLogic Ukraine, 2021
Other open source communities
TL Lim and Pine64 community
