reklama

Android coraz bliżej Linuksa: dobrze jest mieć całkowicie otwarty system

Strona główna Aktualności

O autorze

Hodowca maszyn wirtualnych i psów, poza tym stary linuksiarz, bonvivant i śmieszek. W 2012 roku napisał na DP o algorytmie haszowania Keccak i wciąż pamięta, jak on działa.

Czy Android może być bliższy Linuksa? Tak, wiemy że Android bazuje na Linuksie, ale zarazem architektura systemu niewiele ma wspólnego z tym, co wykorzystywane jest w typowych desktopowych dystrybucjach, a nawet mobilnych systemach (np. Sailfishu czy Tizenie). To jednak powoli się zmienia. W 2011 roku Linus Torvalds powiedział, że kiedyś Android i Linux zejdą się razem, oceniając, że nastąpi to nie wcześniej niż za 5 lat. Efekty tego zbliżenia możemy już obserwować w stosie grafiki.

U podstaw stosu grafiki Androida znajduje się oczywiście linuksowy kernel. Nad nim działa najczęściej własnościowy sterownik producenta GPU – łączący się przez binarny interfejs blob, który właśnie tak bardzo utrudnia aktualizowanie androidowych systemów. W blobie tym znajdziemy alokator pamięci, mechanizmy obsługi OpenGL czy Vulkana itd.

Nad kernelem i jego sterownikiem znajduje się Hardware Composer HAL (obecnie HWC2), częściowo osadzony w sterowniku grafiki i działający w przestrzeni użytkownika. Implementuje on interfejsy grafiki (OpenGL i Vulkan) zestawiając obiekty do wyświetlenia na ekranie i wprowadzając opisujące je abstrakcje, pozwala też wykorzystać sprzętową akcelerację kompozycji, procesu, który samo GPU robi raczej słabo.

Na samym szczycie znajduje się menedżer wyświetlania SurfaceFlinger. Przyjmuje on obiekty graficzne od aplikacji i interfejsu użytkownika (pasek stanu, pasek nawigacyjny, tło), łączy je w jeden bufor ramki i wprowadza go na ekran. Jego komunikacja ze sterownikiem odbywa się właśnie przez HWC2.

Taka architektura sprawia, że wykorzystywane w Androidzie linuksowe jądra są dość przestarzałe. Staraniem Google’a i producentów przenoszone są łatki i poprawki z nowszych wydań kernela, ale trudno tu mówić o długoterminowym wsparciu, większość urządzeń zostaje zapomniana po 2-3 latach – a jeśli społeczność nie dysponuje kodem źródłowym sterowników, to praktycznie nie ma szans, by korzystać z nowych wersji kernela i pozostałych komponentów oprogramowania.

Czy jest szansa, by kiedyś było inaczej, a użytkownicy Androida mogli korzystać z całkowicie wolnego i otwartego systemu, który wspierany będzie przez lata? Pod każdym względem wypada on lepiej, niż własnościowy odpowiednik: regularne aktualizacje bezpieczeństwa, stały dopływ nowości, poprawki błędów, rosnąca wydajność, malejące zużycie energii. Oczywiście dla producentów sprzętu nie wygląda to za dobrze, nie jest w ich interesie, by użytkownik korzystał ze smartfonu dłużej niż 2 lata – więc obecny stan rzeczy może zostać zmieniony tylko przez społeczność.

Robert Foss, entuzjasta otwartego oprogramowania i ekspert od procesorów Freescale i.MX, wystąpił na konferencji Open Source Summit North America, przedstawiając możliwości uruchomienia Androida z całkowicie wolnym stosem grafiki, co w perspektywie otworzyłoby drogę do urządzeń mobilnych ze wsparciem sięgającym 10 lat i więcej, urządzeń, które mogą przeżyć swoich producentów.

Jak wyjaśniał, pozbywając się własnościowego sterownika grafiki, konieczne jest dostarczenie zarówno otwartego sterownika dla samego GPU, jak i implementacji interfejsu programowania HWC2. Na szczęście ten ostatni już powstał, i to w samym Google – jako projekt drm_hwcomposer. Google stworzyło go w bardzo konkretnym celu – chodziło o uruchamianie aplikacji androidowych na ChromeOS-ie, z całkowitym pominięciem implementacji dostarczanych przez producentów GPU. Wykorzystuje on bezpośrednio infrastrukturę renderującą linuksowego kernela (DRM – Direct Rendering Manager), zawiera też allokator pamięci gbm_gralloc i komponenty niezbędne do działania biblioteki grafiki 3D – Mesa.

Sam drm_hwcomposer nie wystarczył jednak, by zapewnić wsparcie dla Androida. Dopiero ostatnie innowacje w kernelu na to pozwoliły. Najważniejszą z nich jest framework synchronizacji, który pozwala wielu komponentom pracować na współdzielonym buforze, dzielić pracę między CPU i GPU. Drugą ważną zmianą jest wprowadzenie interfejsu programowania dla trybu atomicznego w DRM, pozwalającego na uzyskanie doskonałych ramek, rysowanych przy możliwie najmniejszym zużyciu energii. Ponownie, jest to implementacja rozwiązania opracowanego wcześniej przez Google, by poradzić sobie z mnogością niekompatybilnych interfejsów grafiki mobilnych procesorów graficznych.

Oczywiście pozostaje kwestia samych sterowników grafiki. Jeśli szukamy całkowicie otwartych sterowników, sytuacja wygląda znacznie gorzej. Możemy liczyć na niezbyt wydajny dziś już i.MX6 z GPU Vivante gc3000, Snapdragony z serii 400 z GPU Adreno 306 (Qualcomm wydał otwarty sterownik do płytki DragonBoard 410c) oraz Intel HD Graphics z Atomów Bay Trail (płytka MinnowBoard Turbot). Niebawem dojdzie do tego Huawei Kirin 960 z grafiką Mali G71 (płytka HiKey 960).

Szczególnie to ostatnie wygląda obiecująco: jeśli Huawei, jeden z największych dziś na świecie producentów smartfonów, dostarczy na androidowy rynek otwarty sterownik grafiki, może to wpłynąć na Samsunga czy Qualcomma do zaoferowania czegoś innego niż tylko binarne bloby. Urządzenia Huawei z procesorami Kirin mogłyby wówczas mieć zapewnione wsparcie na długie lata – i to bez specjalnych starań producenta.

© dobreprogramy
reklama

Komentarze

reklama