Nie będzie sprzętowej akceleracji wideo w Chrome na Linuksa: winna „niska jakość sterowników”

O niskiej jakości sterowników graficznych na Linuksa mówiłosię już dawno temu, ale wydawać się mogło, że postępy wpracach tak nad otwartymi sterownikami intel, radeon i nouveau, jak iwłasnościowymi fglrx i nvidia* *doprowadziłydo sytuacji, w której być może nie zawsze dorównywały onewydajnością własnościowym sterownikom dla Windows, ale uzyskałyprzynajmniej wystarczającą stabilność, by zapewnić sprzętowąakcelerację grafiki dla wszelkiego oprogramowania. Najwyraźniej takjednak nie jest, nawet dla rozkochanego w Linuksie Google'a.Programiści tej firmy, usprawiedliwiając się niską jakościąsterowników graficznych i mnogością linuksowych dystrybucji,poinformowali że rezygnują z planów włączenia akceleracji wideow Chrome/Chromium dla „Pingwina”.

W połowie 2012 roku Googlewprowadziło do linuksowego Chrome oraz ChromeOS-a własny interfejsprogramowania dla sprzętowej akceleracji wideo o nazwie VAVDA,przeznaczony dla intelowych procesorów Sandy Bridge i nowszych.Pozwalał on na odciążenie CPU przy odtwarzaniu wideo zarówno weFlashu jak i w HTML5 i najwyraźniej był przerobioną nieco wersjąinterfejsu VA-API, opracowanego kilka lat wcześniej przez Intela zmyślą o opensource'owych sterownikach tej firmy. Uruchomienieprzeglądarki z nowym API wymagało podania przy starcie flagi–enable-vaapi, była to więc technologia niestabilna,eksperymentalna. Szybko pojawiłysię zgłoszenia pierwszych usterek powodowanych przez VAVDA –i pomimo kolejnych łatek, sytuacja nie uległa jakiejś znaczącejpoprawie.

Najwyraźniej niewiele sięzmieniło. Wprowadzone niedawno zmiany w Chromium doprowadziły doprzeniesieniakodu kontrolującego sprzętowo wspomagane wideo na czarną listęprocesorów graficznych. Oznacza to, że domyślnie sprzętowejakceleracji wideo w linuksowym Chrome nie będzie, chyba żeużytkownik „siłowo” wyłączy czarną listę, godząc się zpotencjalną niestabilnością oprogramowania.

Inni deweloperzy Chromium chcąjednak posunąć się jeszcze dalej. Ami Fischman przypomniał, żewielu użytkowników wyłącza sobie czarne listy, bo chciałobykorzystać z zablokowanej funkcjonalności, a gdy przeglądarkazaczyna się sypać, po prostu zapominają, co zrobili wcześniej itracą czas na bezowocne próby restabilizacji Chrome. Włączeniesprzętowej akceleracji wideo do czarnej listy GPU doprowadzić bymiało do sytuacji, w której pojawi się w Sieci pełno blogowychwpisów o tym, jak to łatwo włączyć sprzętową akceleracjęgrafiki w Chrome na Linuksie – i ostateczny efekt dla użytkownikówbędzie gorszy (awarie przeglądarki) niż był wcześniej (stabilne,software'owe renderowanie wideo H.264).

Fischman przypomniał też, że wChrome nie chodzi o to, by permanentnie zapewniać eksperymentalne,testowe funkcje, które nigdy nie osiągną dojrzałości. Dlategolepiej byłoby cały ten mechanizm z Chrome usunąć. Poparł go innydeweloper, Jorge Lucangeli Obes, który określił zajmowanie sięGPU na Linuksie koszmaremi uznał, że włączenie sprzętowej akceleracji może nastąpićdopiero po ustaleniu, jak zrobić to bez szkodzenia stabilnościaplikacji.

Pojawiła się w trakcie dyskusjijeszcze jedna, kompromisowa propozycja: wprowadzenia białej listyoficjalnie wspieranych przez Chrome dekoderów wideo w GPU, ale i jąFischman odrzucił, mimo że ułatwiłaby życie deweloperomChromeOS-a. Zbyt wiele jest bowiem różnych sterowników,dystrybucji i sprzętu, by ogarnąć tę kwestię – i wśróddeweloperów Chromium nie widać nadziei, by udało się to zmienić.

Stanowisko to jednak nie do końcaprzekonuje. Nie można zapomnieć, że Mozilla dobrze sobie poradziłaz implementacją białych list – Firefox na opensource'owychsterownikach dla GPU Nvidii i AMD ładnie sobie radzi ze sprzętowąakceleracją, tak dla grafiki 3D, jak i wideo (nawet we Flashu).

Problem tkwi więc chyba bardziejw rozwiązaniach Intela, niż w Linuksie – Nvidia dostarcza od latznakomity interfejs VDPAU, który bezbłędnie sobie radzi zesprzętową akceleracją wideo (o czym dobrze wiedzą wszyscyużytkownicy linuksowych komputerków HTPC z odtwarzaczem XBMC). Cowięcej, implementacja VDPAU niebawem zadebiutuje w opensource'owychsterownikach radeon i nouveau. Czemu więc Google uparcie skupia sięna własnościowym API Intela – czy tylko dlatego, że układyChipzilli dominują na rynku tanich komputerów pod ChromeOS-a?