Jean-Baptiste Quéru, szef projektu AOSP rezygnuje ze stanowiska

Jean-Baptiste Quéru, szef projektu AOSP rezygnuje ze stanowiska

przez -
33 391
Jean-Baptiste Quéru, szef projektu Android Open-Source Project, zrezygnował ze swojego stanowiska. Powodem tej decyzji była frustracja z powodu braku dobrych wolnych sterowników dla kart graficznych w procesorach ARM, co powoduje, że flagowe urządzenia Google nie działają z wolnym Androidem. Szczególnie warto tu wspomnieć o smartfonie Nexus 4 i tablecie Nexus 7, które mają układy Qualcomma, a producent do tej pory nie che udostępnić, ani specyfikacji, ani kodu sterowników.

Jean-Baptiste Quéru był też od ponad 6 miesięcy naciskany przez Google do zrobienia działających sterowników dla AOSPa, przez co ma dość takiego stresu i odpowiedzialności, nie będąc winnym zaistniałej sytuacji. Niby istnieje projekt Freedreno, ale jakość obecnych sterowników i brak obsługi najnowszych układów graficznych pozostawiają wiele do życzenia.

  • MikołajS

    Jeśli taki projekt miałby liczyć na powodzenie, to albo musiałby za tym stanąć jakiś producent hardware albo musieliby zaplanować wydanie własnych urządzeń.

    • pijaczek

      Jeśli liczyć na jakiekolwiek powodzenie to firmy trzecie posiadające patenty i własność na kody w zamkniętych sterownikach (a jest takich masa – licencjonowanych rzeczy przez producentów sprzętu które są w sterownikach zamkniętych) musiałyby się zrzec rozszczeń, całą architekturę sterowników graficznych w jądrze linuksa trzeba by wywalić (podobnie jak cały projekt mesa wyrzucić do kosza) i napisać wszystko od nowa. Ani jedno, ani drugie jest obecnie niewykonalne więc nie liczyłbym na to (a bez tego nie powstaną nawet przyzwoite sterowniki).

      Przykładowo Qualcomm w swoich zamkniętych sterownikach ma całą masę kodu i rozwiązań AMD/ATI (Adreno kiedyś było ich), i jest tylko licencjobiorcą i ten sam kod i rozwiązania znajdują się w zamkniętych sterownikach na PC. Qualcomm bez zgody AMD… i dziesiątek innych firm nic nie zdziała.

    • MikolajS

      Zawsze można cofnąć się o 25 lat wstecz i zacząć od miejsca gdzie przedawniły się patenty :-) Albo próbować opierając się na się na fundacji i licencji Apache uzyskać zwolnienia patentowe dla jakieś architektury. Wszystko to oczywiście tylko hipoteza bo zdaję sobie sprawę jak mała szansa jest na powodzenie takiego scenariusza.
      Swoją drogą ciekawe jak wygląda "obłożenie" patentowe architektury Power którą IBM chce ożywić we współpracy z innymi firmami. Jeśli Intel ma większość patentów to trudno liczyć na równe zasady.

  • pijaczek

    "Szczególnie warto tu wspomnieć o telefonie Google Nexus 7, który ma układ Qualcomma"
    Nexus 7 to nie telefon tylko tablet. I to z procesorem Nvidii… chyba, że mowa o "nowym Nexus 7" który kilka dni tak na dobrą sprawę ma, bo 30 rozpoczęła się sprzedaż to jest on faktycznie z procesorem Qualcomma… ale również nie jest telefonem, a jeśli Jean miałby się na Adreno denerwować to już powinien przy telefonie Nexus 4 wydanym w listopadzie 2012 (ten sam procesor co w właśnie wydanym nowym Nexus 7).

    Co do otwartych sterowników dla GPU to sprawa jest taka jak na PC. Po prostu nie istnieją dobre otwarte sterowniki, nawet ze wsparciem od producentów sprzętu (otwarte sterowniki od Intela na PC, czy otwarte sterowniki od Nvidii dla Tegry… itd). Powód jest prosty – otarte sterowniki nie wykorzystują kodu na które mają patenty firmy trzecie (nie producenci), a dodatkowo korzystają z otwartych architektur sterowników, które są tragicznie napisane i zabiją każdy sterownik.

    • Poprawiłem. Faktycznie chodziło o smartfona i tablet, czyli Nexus 4 i Nexus 7, te najnowsze wersje :)

    • 123qwe

      pijaczek: orientujesz sie moze jak wielka strata jest w przypadku rozwiazania jakie uzyto w SailfishOS – Hybris
      http://en.wikipedia.org/wiki/Hybris_%28software%2

      z tego co wyczytalem to jest to takie "wine" dla androidowych sterownikow. Duze straty sa przy takim rozwiazaniu?

      I dlaczego skoro sa dostepne otwarte stery od intela spolecznosc ich nie poprawi, ulepszy, dopisze brakujacy kod (ktory nie zostal dolaczony ze wzgledu na firmy trzecie), skoro sa one takiej zlej jakosci?

    • pijaczek

      @123qwe: Hybris z tego co pamiętam to po prostu implementacja bionic libc za pomocą glibc. Czyli biblioteka z kompatybilnym ABI z bionic libc przekazuje dane do glibc.

      Ogólnie chodzi o to, że ze względu na to, że glibc się nie do końca nadaje do mobilnych (i innych wbudowanych) urządzeń powstały eglibc, dietlibc, bionic, uClibc, musl i inne. Ze względu na różnice w ABI jeśli coś skompilujesz w jednym, to w innym już nie zadziała. Google wykorzystuje stworzoną przez siebie implementację bionic, a ze względu na zdobytą popularność są na nim sterowniki do wszystkiego. Twórcy zamkniętych sterowników olewają takie SailfishOS, więc nie ma mowy o przekompilowaniu przez nich zamkniętych sterowników pod implementację biblioteki standardowej C wybraną przez SailfishOS czyli glibc, dlatego trzeba udać implementację bionic libc i wykonać to w glibc. Samo to, że musi pośredniczyć da niewielki narzut… jednak samo to, że bionic libc jest sporo szybsze niż glibc może zrobić delikatną różnicę.

      Otwarte sterowniki Intela są takie, że robią minimalnie tylko to co muszą (najniższa komunikacja z GPU) i to robią dosyć dobrze. Problemem jest to, że właśnie najważniejsze pozostawiono społeczności i to, że korzysta z GEM z jądra Linuksa, to że implementację OpenGL pozostawiają społeczności (mesa) wszystko co ważne leży. Właśnie problem jest w kodzie społeczności. Gdyby wywalić kod "społeczności" (KMS z jądra wymuszające GEM, GEM czyli zarządzanie pamięcią i wykonywaniem kontekstu – najważniejsze dla wydajności, a leży i kwiczy, implementacji OpenGL (chociaż w praktyce tak Mesy nie powinno się nawet nazywać, bo to z OpenGL ma niewiele wspólnego)) i firma jak Intel napisała sterowniki sama od początku do końca (a nie tylko podpięcie się pod społecznościowe projekty) miałoby to ręce i nogi, a tak to szkoda gadać.

    • 123qwe

      Czyli jesli chodzi o SailfishOS to nie jest zle.. a juz sie przestraszylem.

      Co do sterow intela i innych.. z tego co zrozumialem to Wayland w takim razie, ktory wymusza KMS, nie jest dobrym rozwiazaniem gdyz wymusi tez uzywanie MESY itd. i MIR, ktory pozostawi otwarta furtke dla zamknietych sterow i ich wlasnych implementacji OpenGL itd. moze sie okazac lepszym wyjsciem?

      Z drugiej strony to wydawalo mi sie, ze kod ktory trafia oficjalnie do linuxa powinien byc jak najwyzszej jakosci a w tym przypadku chyba tak nie jest.

    • pijaczek

      @123qwe: KMS nie wymusza MESY. KMS wymusza skorzystanie z GEM (dużo gorsze niż sama Mesa mimo, że ta jest tragiczna). I tak – Wayland jest pod tym względem do dupy co komentowała zarówno Nvidia jak i AMD.

      Do jądra Linuksa trafia to co jest najlepsze dla rozwoju. Osób rozwijających otwarte sterowniki dla GPU jest niewielu, więc nie można robić dobrych sterowników specjalnie dla każdego GPU osobno, bo do żadnego GPU sterowniki by nie istniały. Postanowiono zrobić coś innego czyli GEM – zunifikować wszystko (mimo olbrzymich różnic w sprzęcie), OLBRZYMIM kosztem wydajności. Po prostu w wypadku sterowników otwartych postawiono na ilość wspieranego sprzętu, a nie na jakość tego wsparcia (ustalono, że jeśli chcesz dobre wsparcie to użyj zamkniętych pisanych z myślą o tym sprzęcie).

    • sprae

      Dzięki Pijaczek za wiedzę jaką się dzielisz :-)

    • Sebastian

      Dzięki za rzucenie konkretnego światła na problem. Krótko mówiąc syf, kiła i mogiła. Jedyna dobra opcja to PC z kartą od Nvidia'i.

    • 123qwe

      Rowniez wielkie dzieki za wyjasnienie, zaczynam w koncu mniej wiecej rozumiec gdzie lezy problem.

      Zastanawia mnie jeszcze jedna rzecz czy naprawde jest niemozliwym napisac sterowniki pod Waylanda w ten sposob by napisac wlasne zamkniete rozwiazania KMS, GEM i podmienic moduly w jadrze, tak by bylo to kompatybilne z Waylandem czy jest to poprostu wymowka?

      W zwiazku z tym, ze GEM to jest rozwiazanie dla duzej ilosci sprzetu czy idzie przekompilowac go z obsluga tylko jednej karty? To powinno zwiekszyc jego wydajnosc.

    • sprae

      Przecież Pijaczek napisał, że nie ma kto tego robić. Dlatego to ujednolicali.

    • pijaczek

      Obecnie Wayland mocno wymusza użycie KMS… jednak jak Nvidia napisze sterowniki dla EGL z własną implementacją zarządzania pamięcią i pracą GPU to pewnie znajdą jakiś sposób aby to obejść (bo jak nie to oddadzą walkę o nowy serwer wyświetlania walkowerem Mirowi).

      Z GEM nie da się zrobić tak aby było szybko, bo jego architektura jest zunifikowana i nie da się zrobić aby było to wydajne na jakiejkolwiek karcie nawet jeśli byłaby to tylko jedna (dla GEM to nieistotne ile sterowników z niego korzysta i działa zawsze tak samo – nie można go "skompilować z obsługą tylko dla danej karty", bo on nie obsługuje żadnej karty, ani sterownika… to sterownik jest skompilowany i napisany tak aby korzystał z GEM, a nie odwrotnie – on jest tylko zunifikowanym pośrednikiem, a przez to zunifikowanie jest bardzo wąskim gardłem). Jedyne co da się zrobić to olać KMS i GEM i zrobić osobno implementację specjalnie dla danego GPU jak to robi Nvidia czy AMD w zamkniętych sterownikach (otwarte sterowniki też tak mogą zrobić olewając GEM… problem w tym, że nie ma osób do pracy i wolą ujednolicić).

    • sprae

      A tu coś z szerszej perspektywy, o tym dlaczego OpenGL przegrał http://programmers.stackexchange.com/a/88055

    • pijaczek

      Nie chce mi się czytać, ale po pierwsze nie przegrał, a na jakiś czas stał się mniej popularny (dziś odzyskuje formę), bo po prostu był gorszy:
      – Był mniej wieloplatformowy. DX przejął pałeczkę pierwszeństwa za czasów pierwszego Xboxa czyli na PC i konsolę MS można było pisać w DX, a OpenGL tylko na PC (a Windows wtedy w przeciwieństwie do dzisiaj miał prawie cały rynek). Dziś miano tego wieloplatformowego odzyskał OpenGL za sprawą powiększenia udziałów MacOS i Linux oraz ze względu na mobilne urządzenia i 3d w przeglądarkach które jest przez OpenGL zdominowane (iOS/Android i WebGL w przeglądarkach).
      – Ze względu na tragiczne sterowniki… głównie od AMD i Intela w tamtych czasach, podczas gdy Microsoft sam testował zgodność i dla DX były przyzwoite. Teraz na szczęście zarówno AMD jak i Intel (ten tylko pod Windowsem i MacOS) poprawili swoje sterowniki.
      – I ostatnie, ale nie najmniej ważne… brak rozwoju kiedy jeszcze Microsoft był w ARB i miał wpływ na rozwój OpenGL. Dopiero w połowie 2006 r. rozwój ruszył, kiedy powołano Khronos Group i ARB przekazało im zarządzanie nad OpenGL i od wtedy nadrobił lata strat do Dx tak, że obecnie jest od Dx lepszy.

    • sprae

      Jest tam jeszcze ciekawy wątek o GLSL, który zmusza producentów do tworzenia kompilatorów na własną rękę. Może na desktopie dziś to jakoś działa, ale na mobilnych dalej jest w powijakach. Dochodzi do takich patologii, że niektóre kompilatory wcale nie czytają dyrektyw preprocesora, a inne zawieszają się w dziwnych momentach.
      Z drugiej strony stoi Nvidia ze swoim kompilatorem opartym na Cg, który jest niezwykle liberalny w stosunku do standardu (np. pozwala na rzutowanie niejawne).

      W DX autor cieszy się z tego, że kompilator pisze Microsoft, jako jeden standard. Kompilator wystawia na dodatek unifikowane Assembly, które można optymalizować. Z resztą dziś DX11.2 pozwala nawet na dynamiczną zmianę kodu shaderów i biblioteki, co w OpenGL jest kulawe.

    • Kluskap'o'Kom

      O jakim standardzie mówisz? Cg-toolkit nie jest zgodny ze standardem GLSL, jest raczej jego konkurencją.

    • pijaczek

      Na kompilatorze Cg opiera się kompilator GLSL (a przynajmniej opierał się) – ten który jest zaszyty w sterowniki.

      Ten kompilator z Cg toolkit jest jak najbardziej zgodny GLSL. CGC potrafi z kodu Cg kompilować do GLSL i innych targetów (ASM itp), ale też jeśli podasz mu flagę -oglsl lub -ogles to ustawisz, że ma kompilować kod napisany w GLSL (w wersji mobilnej lub desktopowej).

      Sam język Cg (nie jego toolkit, a sam język) to jak najbardziej konkurencja GLSL… bo to nic innego jak język HLSL z DirectX (Nvidia i Microsoft razem stworzyły ten język, ale własne implementacje inaczej nazwali).

    • pijaczek

      To nie GLSL zmusza producentów do tworzenia kompilatorów, a to właśnie producenci sprzętu (z których składa się Khronos) chcieli sami mieć wpływ na kompilację i kompilacja odbywa się online (podobnie jak to wygląda w OpenCL, ale ostatnio zapowiedziano OpenCL SPIR, który pozwala na kompilacje offline jak w Dx).
      Na mobilkach nie zauważylem, żeby nie czytały dyrektyw preprocesora, a testowałem na Tegra 2/3, Mali 400, Adreno 220/320, PowerVR 540, a nawet Vivante… Problem jest z optymalizowaniem kodu w PowerVR, dlatego na mobilkach stosuje się GLSL Optimizer, który robi proste optymalizacje które powinien robić kompilator.

      Nvidia w swoim opartym o Cg kompilatorze miała pozwalała na więcej niż było zapisane w standardzie, ale to za czasów OpenGL 2.0 (i łatwo było to wykryć czy się nie wykracza poza specyfikację). Teraz już od GL3+ wywala każdy błąd na etapie kompilacji, linkowania lub validacji, a jeśli korzystasz z rozszerzenia debuggowania to Ci wszystko ładnie opisuje.

      Microsoft pisze jeden kompilator do kodu pośredniego. Pozwala to na ujednolicenie optymalizacji i analizy kodu. Jednak dalej sporo zależy od sterowników i jak ten kod pośredni przekładają na kod dla GPU.
      W GLSL też możesz skompilować sobie do ASM zunifikowanego – dokładniej ARB assembly language możesz wygenerować za pomocą wspomnianego kompilatora Cg (przyjmuje jako wejście język Cg, GLSL lub GLSL z OpenGL ES).
      Co do dynamicznej zmiany kody shaderów to nie rozumiem o co Ci tu chodzi… bo znacznie łatwiej się to robi w GLSL właśnie ze względu na brak operowania na prekompilowanych plikach. To co Microsoft zrobił w Dx11.1 to właśnie pozwolił na kompilację online (nie prekompilowane przez programistę, a kompilację w czasie uruchomienia aplikacji)… czyli zrobił to co dla OpenGL naturalne.

    • Klamk

      Tak z ciekawości, czym się zajmujesz zawodowo, bo raczej wątpie żeby tak obszerna wiedza była wynikiem samego tylko hobby?

    • pijaczek

      Programowanie grafiki 3D w silnikach gier za pomocą GL i DX. Wiedza zdobywana z różnych dokumentów teoretyczna i popierana doświadczeniem praktycznym. Przykład ze znajomością problemu z Cg i sterownikami Nvidii to miałem problem z przepisywaniem kodu shaderów z Cg do GLSL – nie sprawdziłem czy istnieje wbudowana funkcja mul() dla mnożenia macierzy przez wektory, bo założyłem, że tak i faktycznie kod działał na sterownikach Nvidii, ale wystarczyło przepuścić przez AMD ShaderAnalyzer, aby podpowiedział, że mul() w specyfikacji GLSL nie istnieje i trzeba zaimplementować ręcznie.

    • iniside

      NVIDI raczej rowno lezy ktory serwer wyświetlania wygra, bo oni tylko pisza sterowniki, i beda je pisać pod to co wygrało rynek.

      Swoja droga czy Wayland sam w sobie wymusza na sterownikach wykorzystanie GEM, czy jest mu objetne w jaki sposob sterownik karty graficznej zarzadza pamiecia. Jeśli to pierwsze to, osoby odpowiedzialne za GEM powinny zawisnac. GEM powinno byc tylko fallbackiem. Jądro powinno poprostu udostępniac interfejsy, pod które sterownik karty graficznej moze podpisac swoje wlasne zarzadzanie pamiecia GPU. Tzn, przynajmniej tak mi sie wydaje, ktos kto lepiej sie na tym zna moglby napisać jakby takie teoretyczny system mogl wygladac.

      Swoja droga swietne komentarze, moglbys jakis artykuł na ten temat napisać jakby ci sie chciało. Fajnie sie czytało, probowalem wiecej na ten temat poszukać, ale szczerze mowiac, albo nie wiem jak sie to zabarać, albo ilosc dostepnych informacji jest poprostu bardzo mała.

    • pijaczek

      Nvidii nie leży to, że ktoś im chce narzucać jak pisać sterowniki tym bardziej jeśli nakazuje zrobić to bardzo źle i niewydajnie.

      Wayland wymusza korzystanie z KMS, a ten z kolei bez GEM się obyć nie może. GEM to nie tylko zarządzanie pamięcią, a całym kontekstem wykonywania (czyli praktycznie wszystkim).
      Nie odpowiedzialne za GEM powinny zawisnąć (GEM jest do dupy, ale postanowiono, że lepiej mieć do dupy sterowniki do wszystkiego niż kilka lepszych). To osoby odpowiedzialne za Waylanda powinny zawisnąć. Ani X11, ani Mir nie wymagają KMS, przez co sterowniki mogą robić co chcą – zamknięte olewać KMS i GEM, a otwarte mogą korzystać z GEM i KMS.

    • iniside

      http://aseigo.blogspot.com/2013/02/a-release.html
      Martin Gräßlin
      "@P.Jay: "So with Wayland depending on KMS I see big problems coming."
      and Wayland does not depend on KMS. QtWayland runs on the raspberry pi – proprietary driver, no KMS and still: it works. Wayland is just a protocol to exchange buffers.

      You are not the only one getting it wrong, there is lots of FUD around Wayland especially as people get confused about what Wayland allows and what Weston (reference implementation of a Wayland compositor) requires.

      I don't see any reason why Wayland should not work with NVIDIA's driver and personally I'm sure that the driver already supports it in the NVIDIA labs. "

      Jesli wierzyc Martinowi, to Wayland jednak nie wymaga KMS/GEM do działania, tylko Westom ktory na nim siedzi.

      Z drugiej strony, wyzej pisze ze KWin tez bedzie wymagał KMS, co prawde mowiac według mnie w tym momencie zakrawa na smiesznosc.

    • Kaleson

      Martin Gräßlin – "I want to experiment with having KWin run on top of KMS or on top of another Wayland compositor."
      http://blog.martin-graesslin.com/blog/2012/09/a-r

    • pijaczek

      Martin Gräßlin bardzo ładnie opowiada, ale niestety bzdury. Mówi FUD o rzeczy którą sam początkowo projektował i tak działało długo i pod naciskami zmienił trochę architekturę.

      Wayland obecnie oficjalnie nie wymaga KMS, ale jego architektura zmusza managery kompozycji do korzystania z KMS, czego efektem jest Wayland, KWin czy Mutter (czyli uniwersalny kompozytor, kompozytor KDE, kompozytor Gnome…) wymuszają KMS (i to nie przez własne widzimisię, czy tak jak już Martin mówił brak alternatyw, bo już 1.5 roku mamy chociażby implementację dla desktopów od AMD, a od Nvidii, Qualcomma i innych na mobilne sprzęty w wersjach dla Linuxa i Androida).

      Co więcej na stronie Waylanda w sprawie przytoczonego Raspberry Pi potrafią kłamać, że dlatego wyłączyli wsparcie dla bezpośredniego renderingu na GPU jak i wsparcie dla EGL przez brak wsparcia EGL przez twórcę układu i, że nie istnieje implementacja EGL dla tych zamkniętych sterowników, podczas gdy Broadcom daje implementacje EGL, a jedynym powodem faktycznym braku wsparcia jest to, że nie korzysta z KMS.

    • iniside

      Czyli jak zwykle poszło o głupią idelogie ? Dałoby sie, ale zrobimy tak bo tak.

  • Greg

    Jutro

  • ziutek

    @pijaczek

    “jednak samo to, że bionic libc jest sporo szybsze niż glibc może zrobić delikatną różnicę.”

    Bez jaj, zarzucanie glibc powolność zakrawa na dobry żart.

    <a href="http://www.etalabs.net/compare_libcs.html” target=”_blank”>www.etalabs.net/compare_libcs.html
    Google, użyło bionic tylko z powodu licencji. Bloatware glibc było istotne w czasach embeded z 2MB RAM i 64MB przestrzeni na system plików.

    Swoją drogą co to za obyczaj na polskich portalach z całkowitym brakiem aktualizacji i odniesienia do artykułów, które po dwóch dniach się deaktualizują.

    • pijaczek

      Link zupełnie nie pasujący do tematu – ani tam nie ma glibc (jest dużo szybszy, obcięty z wielu rzeczy jest eglibc, który tam jest), ani bionic (dużo szybszy od eglibc). Wielką bzdurą jest to, że Google zrobiło to z powodu licencji… licencja glibc to LGPL i nie ma problemu z wykorzystaniem glibc w zamkniętym projekcie, a z libc i tak się linkuje dynamicznie (w androidzie zawsze) więc od strony ograniczeń licencyjnych problem nie istnieje (z LGPL mógłby być problem przy linkowaniu statycznym, ale nie ma o tym mowy w wypadku libc). Licencja tu w żadnym wypadku nie jest problemem.

      Google stworzyło bionic głównie ze względu na zasoby. GLIBC jest olbrzymi i powolny, dlatego powstał EGLIBC, czyli poobcinany GLIBC – dużo mniejszy i wydajniejszy, jednak dalej na tle musl czy jeszcze bardziej na tle bionic wygląda źle.