Konkrétně Mutter vše nahrává do OpenGL textur takže hodně záleží na rychlosti grafické karty a kvalitě ovladačů. To je také důvod proč EGLStreams a nefunkční otevřené ovladače pro NVIDA jsou pro Mutter/Gnome tak velký problém.
Odezva prohlížeče
Testy jsem prováděl na Speedometer 2.0, což je test obecné rychlosti odezvy prohlížeče a je součástí tréninku PGO. Na svém pracovním PC (Lenovo T460p/i7/Intel HD Graphics 530) jsem měřil aktuální oficiální balíček Firefox z Fedory s povoleným WebRenderem, Chrome od Google a balíček Chromium z Fedory.
Skóre v Gnome Shell Wayland/XWayland sezení
| Firefox WR Wayland | Google Chrome XWayland | Chromium XWayland |
| 66,6 | 69,0 | 55,3 |
Skóre v Gnome Shell X11 sezení
| Firefox WR Wayland | Google Chrome |
| 70,8 | 70,2 |
Jak je vidět, Firefox WR a Google Chrome jsou ve Speedometeru v nativním X11 stejně rychlé, zatímco Wayland/XWayland lehce zaostává. Netuším, proč má Chromium na Fedoře o tolik horší skóre, ale tipuji to na absenci optimalizace PGO/LTO při překladu.
Mimochodem Firefox distribuovaný Fedorou je díky GCC o chlup rychlejší než oficiální binárky od Mozilly.
Přehrávání videa
Velmi podobné výsledky dostaneme u přehrávání videa H.264. Firefox i Chrome/Chromium video dekódují pomocí knihovny libav (ffmpeg), snímky se následně uploadují do GL textur a pomocí shaderu konvertují z formátu YUV do RGB a vykreslí.
Jako benchmark jsem použil video H.264 v rozlišení 1920×816 pixelů. Firefox díky podpoře Waylandu/HiDPI vykresloval v rozlišení 4K a jak vidíme, výsledky jsou v podstatě totožné.
Otázka je, jak by test dopadl při povolení akcelerace VAAPI v Chrome. Bohužel se mi to na mé konfiguraci nepovedlo zprovoznit, takže budu rád za případné postřehy v diskuzi.
Dma-buf a zero copy
Pod pojmem „zero copy“ se v IT rozumí dekódování snímků (video, web) přímo do paměti grafické karty bez dalších mezikroků. Používá se hlavně na mobilních zařízeních, na Linuxu je v kernelu implementováno pod názvem DMA Buffer Sharing and Mesa, nadstavba se jmenuje GBM. Právě toto je problém u NVIDIA, která má svoji vlastní implementaci EGLStreams ve vlastní implementaci OpenGL a nepoužívá otevřenou knihovnu Mesa GL.
Proti tomu na PC se obvykle kreslí do SHM (sdílená paměť) a ta se předá kompozitoru nebo se uploaduje do grafické karty přes OpenGL, kde obsluhování konkrétního HW (EGLStreams/GBM) má na starosti implementace OpenGL, včetně uploadu textur do GPU.
Na první pohled vypadá jako ideální řešení upload rovnou do GPU, v prvotním nadšení jsem do Firefoxu na Waylandu také implementoval podporu pro GBM a Firefox dokáže kreslit přímo do paměti na grafické kartě. Stejně tak je na Waylandu k dispozici GBM pro OpenGL a WebRender. Ovšem moje nadšení rychle opadlo při prvních testech. Ukázalo se, že GBM je dokonce pomalejší než standardní vykreslování přes SHM.
Důvodem jsou nejspíše modifikátory. Grafické čipy už dávno obsahují hromady optimalizací pro upload/rendering textur, jako rozdělené buffery (každá barva má svůj vlastní buffer, popřípadě oddělené RGB a Alfa buffer), upload komprimovaných textur nebo tiling (rozsekání bufferu na menší čtverce, např. 128×128 pixelů).
Toto všechno za nás v GL obstará glTexImage2D() a výsledný formát textury a konkrétní uložení na grafické kartě nemusíme řešit. Proti tomu, pokud se dělá zápis do GPU „ručně“, nic z těchto vychytávek nelze použít. Knihovna Skia (zdroj grafiky ve Firefoxu/Chrome) nic takového neumí a dokáže vyplivnout jen standardní lineární grafický buffer, bez tilingu/komprese/separátních rovin. Představte si, jak neoptimální je potom použití podobného bufferu přímo na GPU.
Existují pouze dva případy, kdy přímé použití GBM ve Firefoxu má smysl. První je WebGL, kdy se GL scéna renderuje do bufferu GBM a zůstane tedy na grafické kartě pro další použití a HW dekódování videa, kdy libav/VAAPI dokáže produkovat video snímky jako GBM buffery. Bohužel obojí zatím ve Firefoxu chybí a upřímně řečeno na X11 se toho už ani nikdy nedočkáme.
Co nás ve Firefoxu na Linuxu čeká v budoucnu?
Lidé pracující výhradně na linuxové verzi Firefoxu se dají spočítat na prstech jedné šestiprsté ruky a nikdo z nich není z Ubuntu. Proto také vývoj nejde kdoví jak rychle kupředu. Poslední dobou se ale docela daří alespoň v technologické rovině dotahovat nesporný náskok Chrome.
Rychlost WebRenderu je srovnatelná a projekt Fision slibuje dorovnat náskok Chrome v izolaci vnořeného obsahu. Na Linuxu se například chystá nasazení Picture-In-Picture nebo integrace vyhledávání pro Gnome Shell.
A určitě se dřív nebo později na Waylandu dočkáme i akcelerace WebGL a VAPPI, a to primárně na Fedoře, jelikož Red Hat dodává do projektu podstatnou část oněch zmiňovaných linuxových vývojářů.
ČLÁNKY DO MAILU