Od pewnego czasu użytkowników elektryzują nowe efekty graficzne, które powoli pojawiają się na pulpitach naszych komputerów. Hasła takie jak AIGLX, XGL, Beryl czy Compiz coraz częściej pojawiają się w dyskusjach, jednak początkującym ogarnięcie tych technik może sprawiać odrobinę kłopotów. Ten artykuł postara się wyjaśnić „co z czym” i „dlaczego”.

Żeby jednak móc opowiadać o kompozytowych menedżerach okien, należy rozpocząć od początku, czyli od systemu X Window.

Na początku był X

W DOSie i w systemach pochodnych zasada wyświetlania obrazu na ekranach komputerów była prosta – system operacyjny miał bezpośredni dostęp do pamięci ekranu (lub karty graficznej) i zmieniając zawartość pamięci manipulował obrazem. Zresztą nie musiało się to dziać poprzez system operacyjny, bo programy uruchomione w DOSie również mogły manipulować pamięcią ekranu. Przykład? Proszę bardzo. Jeszcze kilka lat temu pisząc dowolny program w Turbo Pascalu można było dobrać się do zawartości ekranu w trybie tekstowym, która to zawartość czekała spokojnie pod adresem B000:0000. Oczywiście wraz z rozwojem techniki i nadejściem trybów ekranu lepszych niż VGA oraz trójwymiarem sprawa się ciut skomplikowała, ale podstawa była właśnie taka: system operacyjny bezpośrednio, lub poprzez sterowniki ekranu, manipulował pamięcią ekranu podłączonego lokalnie do komputera.

Systemy operacyjne mające źródła w Unixie mają zupełnie inną filozofię wyświetlania obrazu na ekranie monitora. Wymusiły to terminale, czyli – mocno upraszając sprawę – wiele końcówek z własnym monitorem i klawiaturą podłączonych do jednej jednostki centralnej. Wszystkie programy były uruchamiane na jednym serwerze, ale każdy z użytkowników siedział przy własnej klawiaturze i na własnym monitorze widział wyniki pracy.

Żeby to obsłużyć powstał X Window System. Ów system, który idealnie nadawał się do pracy z tekstem i grafiką 2D, działał w architekturze klient-serwer. Rolę serwera spełniała końcówka, czyli monitor, klawiatura lub mysz, a klientem były programy działające na jednostce centralnej. Oczywiście klawiatura i monitor mogły być podłączone nie do terminala, ale bezpośrednio do jednostki centralnej, ale nawet wtedy procesy klienta (uruchomione programy) i serwera (procesy obsługujące klawiaturę czy ekran) były od siebie oddzielone.

Obrazek 1. Działanie serwera X

W tym momencie warto wyjaśnić jeszcze jedną kwestię, a mianowicie czym są menedżery okien. System X dostarcza tylko podstawową funkcjonalność, a mianowicie pozwala na rysowanie prostych elementów graficznych (kwadrat, linia, itp.). Żeby z takich elementów złożyć okno, w dodatku z możliwością skalowania i przesuwania, konieczny jest menedżer okien. Takimi menedżerami są np. Metacity w Gnome, albo KWin w KDE. To właśnie one obliczają położenie okna na ekranie, reagują na przesuwanie i zmianę wielkości okien, a następnie wysyłają do serwera X polecenia rysujące. Dla serwera X właśnie menedżer okien jest klientem, z którym on się komunikuje.

Wchodzimy w trzeci wymiar

Wszytko zaczęło się zmieniać, gdy pojawiła się trójwymiarowa grafika wspomagana akceleracją na karcie graficznej. Żeby oprogramowanie mogło korzystać z mocy obliczeniowej drzemiącej na GPU, sterowniki karty graficznej wystawiały w kierunku oprogramowania zestaw procedur, których uruchamianie wykonywało określoną czynność, np. utworzenie bryły w jakimś miejscu w przestrzeni, lub zapalenie światła. Najbardziej znanym zestawem procedur jest OpenGL, ale jeżeli ktoś chce, to w Microsoft Windows może skorzystać z DirectX.

Jak jednak skorzystać z procedur sterownika karty graficznej, skoro programy nie mają do niego dostępu, a sama karta jest schowana za serwerem X? Jak programy korzystające z OpenGL mają działać w Linuksie?

Powstały dwa rozwiązania tego problemu. Pierwszym rozwiązaniem jest użycie biblioteki Mesa, która udaje, że jest kartą graficzną. Mesa wystawia w kierunku programów kompletny zestaw procedur OpenGL, ale wywołanie tych procedur tłumaczy na komendy zrozumiałe przez serwer X, a następnie rysuje obraz na ekranie korzystając z serwera X. Plus takiego rozwiązania jest ogromny: nawet, gdy nie możemy skorzystać z jakiejś procedury OpenGL, bo dostawca sterowników o tym zapomniał (o tym za chwilkę), to zawsze możemy skorzystać z biblioteki Mesa. Jest jednak minus takiego rozwiązania. Całość działa wolno, bo moc obliczeniowa karty leży odłogiem, a obliczenia trójwymiarowe są przeprowadzane na procesorze.

Drugie rozwiązanie jest oparte na pewnej możliwości wbudowanej w serwer X. Funkcjonalność serwera X może być zwiększana poprzez stosowanie rozszerzeń, np. rozszerzenia pozwalającego korzystać z protokołu GLX. Protokół GLX służy do wymiany informacji o wywołaniu procedur OpenGL pomiędzy aplikacjami (a dokładniej pomiędzy bibioteką libGL) i serwerem X, który te wywołania przekazuje bezpośrednio do sterownika karty graficznej. Otwarta biblioteka zawierająca rozszerzenie w serwerze X nazywa się libglx, ale twórcy kart graficznych dostarczają własne, zamknięte biblioteki.

Obrazek 2. Indirect rendering

Ten sposób wykorzystania karty graficznej nazywa się indirect rendering, czyli „rendering pośredną, ponieważ programy nie mają bezpośredniego dostępu do karty graficznej, a wszystkie polecenia rysujące obraz przechodzą przez serwer X. Całość, chociaż o wiele szybsza niż użycie biblioteki Mesa, ciągle jest zbyt wolna dla niektórych programów.

Gry są zachłanne

Niektóre programy, zwłaszcza gry, wymieniają z kartami graficznymi ogromne ilości danych. Geometria potworów, ścian i broni, tekstury, podprogramy dla vertex i piksel shaderów… Sporo tego. Przepuszczanie tych informacji przez serwer X może spowodować, że przeciwnicy zdążą gracza przedziurawić, pociąć i jeszcze po nim pozamiatać, zanim gracz zdąży nacisnąć spust broni. Gra potrzebuje obejścia serwera X i bezpośredniego dostępu do karty graficznej.

Żeby to osiągnąć, trzeba jednak odłożyć funkcjonalność serwera X na bok. Jeżeli program ma mieć bezpośredni dostęp do karty, musi działać na tym samym sprzęcie, na którym działa karta. Nie może to działać przez sieć, więc dla maszyn, które muszą skorzystać z OpenGL przez sieć pozostaje albo GLX, albo Mesa.

Producenci kart graficznych dostarczają zamknięte biblioteki libGL, które użyte w aplikacjach bezpośrednio komunikują się ze sterownikami karty graficznej. Protokół komunikacji został zestandaryzowany i nazywa się DRI (Direct Rendering Infrastructure), a sposób wykorzystania karty graficznej to direct rendering, czyli rendering bezpośredni.

Obrazek 3. Direct rendering

Tak więc przy wykorzystaniu direct rendering aplikacje okienkowe działają tak, jak do tej pory, czyli poprzez serwer X, ale programy korzystające z OpenGL komunikują się z kartą graficzną bezpośrednio. Rozwiązanie nie jest proste, ale póki co nic lepszego nie wymyślono.

Przyspieszanie okienek

Rozwój techniki spowodował, że dzisiejsze komputery mają spore zasoby i moc obliczeniową, która nie zawsze jest wykorzystywana. Korzystamy z niej podczas skomplikowanych obliczeń, albo podczas grania w nowe gry 3D, ale na co dzień – podczas przeglądania stron internetowych, czy pisania maili – ta moc leży odłogiem. I tutaj dochodzimy do tematu, który od pewnego czasu elektryzuje użytkowników. Ktoś wpadł na pomysł, by część mocy obliczeniowej, która jest w danym momencie niewykorzystana, użyć w innym celu, na przykład do uatrakcyjnienia pulpitu. W chwili obecnej istnieją dwa konkurencyjne rozwiązania, które pozwalają osiągnąć zamierzony efekt: utworzony przez tandem Novell i Suse XGL (X-to-OpenGL), oraz produkt Red Hat nazwany AIGLX (Accelerated Indirect GLX).

Za XGL kryje się bardzo prosty pomysł, choć zdecydowanie skomplikowany w implementacji. XGL to zwykły serwer X, który wciska się pomiędzy już istniejący serwer X oraz aplikacje. Programy, zamiast wysyłać polecenia serwerowi X, wysyłają je do XGL, który tłumaczy cały obraz na 3D, a następnie za pomocą poleceń OpenGL i serwera X leżącego „pod spodem” wyświetla go na ekranie. Serwer X pod spodem jest potrzebny na początku pracy, by XGL mógł poprzez niego nawiązać kontakt z kartą grafiki. Potem XGL komunikuje się z kartą grafiki bezpośrednio, używany jest tutaj direct rendering.

Obrazek 4. Schemat XGL

XGL, jak wszystko, ma swoje plusy i minusy. Plusem jest to, że XGL do działania wymaga jedynie serwera X ze sprzętową akceleracją grafiki. Co więcej, nawet jeżeli jakaś procedura OpenGL nie jest zaimplementowana w sterownikach grafiki producenta karty, to XGL wykonuje ją programowo, za pomocą biblioteki Mesa. Mam tu na myśli procedurę GLX_EXT_texture_from_bitmap, która zamienia okienka zapisane w pamięci komputera na tekstury nakładane potem na obiekty 3D, a która niestety nie jest zaimplementowana w zamkniętych sterownikach ATI.

Jest jednak i druga strona medalu. Ponieważ XGL jest pomostem łączącym aplikacje z kartą, wszystkie odwołania do serwera X, łącznie z przyśpieszanymi operacjami 3D, muszą przejść przez XGL. Aplikacje nie mają dostępu do karty graficznej i właśnie dlatego mogą one korzystać z akceleracji 3D tylko poprzez libGL XGLa, czyli indirect rendering. XGL, jako pomost, sprawia również sporo kłopotów – problemy z układem klawiatury i niedziałające tunery TV to tylko drobne przykłady.

W przeciwieństwie do XGLa, który na nowo odkrywa koło, AIGLX nie jest czymś dodatkowym, a jedynie modyfikacją istniejącego serwera X. Aplikacje mają dostęp do karty graficznej poprzez direct rendering tak, jak do tej pory. Jedyna nowość polega na tym, że sam serwer X również może za pomocą akceleracji sprzętowej wyświetlać obraz 3D.

Obrazek 5. Schemat AIGLX

W porównaniu z XGL ten sposób wyświetlania ma sporo zalet i tylko jedną wadę. Jest o wiele szybszy i bardziej wydajny, ale do działania wymaga wspomnianej już metody GLX_EXT_texture_from_bitmap… Ta procedura jest ujęta w sterownikach NVIDII, Intela i otwartych sterownikach dla kart Ati, ale niestety ktoś zapomniał o niej przy tworzeniu fglrx, czyli zamkniętych sterowników Ati. I tu leży pies pogrzebany, bo otwarte sterowniki dla Ati nie obsługują najnowszych modeli tej firmy. Posiadacze kart nowszych niż Radeon x850 są zmuszeni skorzystać ze sterowników zamkniętych (fglrx), a co za tym idzie, są skazani na XGL lub na nieużywanie XGL/AIGLX w ogóle. Zresztą otwarte sterowniki nie do końca wspierają akcelerację 3D w kartach od Radeona 9500 do x850 i używanie akcelerowanych okienek może nie być tak wygodne, jak powinno…

Jej! Jaka ładna kostka!

Wyświetlanie okienek w AIGLX lub XGL nie jest takie proste i wymaga dość ścisłej współpracy pomiędzy serwerem X i menedżerem okien. Dlatego zwykłe menedżery zostały zastąpione przez menedżery kompozytowe, np. Compiz lub Beryl. Potrafią one wysyłać do serwera X polecenia rysujące okienka, a następnie modyfikować wygląd okien poprzez dodanie cienia, nałożenie przezroczystości lub ich wykrzywienie. To one są odpowiedzialne za wszelkie efekty widoczne na monitorze. XGL i AIGLX są tylko podstawą, która umożliwia akcelerację tych efektów.

Jeszcze do niedawna Compiz i Beryl były dwoma konkurencyjnymi projektami o wspólnych korzeniach. Compiz opierał się na jakości kodu i stabilności, podczas gdy w Berylu ważniejsze były efekty i bajery. Compiz był kiepski w konfiguracji, bo jedynym sposobem zmiany ustawień była ich ręczna edycja w gconfie. Beryl przygotował specjalny wygodny menadżer do zmiany ustawień… Jednak niedawno oba projekty się połączyły i teraz będą wspólnie tworzyć jeden menedżer, w którym z Compiza przyjęto stabilne jądro, a z Beryla pluginy i program do konfiguracji. Czas pokaże, co z tego wyjdzie.

Powrót do przyszłości

Uatrakcyjnianie pulpitów to nieodwołalna przyszłość i, sądząc po obecnych tendencjach, już niedługo nasze pulpity będą jeszcze ładniejsze i jeszcze bardziej efektowne. Wystarczy powiedzieć, że XGL i AIGLX to nie jedyne projekty dążące do wprowadzenia okienek w trzeci wymiar. Microsoft wystartował ze swoim Aero w Windowsie Vista, powstał napisany w Javie Looking Glass, a obecna implementacja XGL (nazywana XGLX) ma być zastąpiona na pozbawioną wad XEGL… I choć nie wszystkich bawią żelujące okna, albo obracająca się kostka, to warto skorzystać z dobrodziejstw nowych technologii. Chociażby dlatego, żeby odciążyć procesor i przenieść obliczenia dotyczące okien na kartę graficzną.