Wielu z was słyszało zapewne o nowych efektach graficznych, które zagościły na dobre na pulpitach naszych komputerów. Oglądaliście filmiki na youtube czy google video, zastanawiając się nad odpaleniem tego u siebie. Nie, ten artykuł nie odpowie wam na pytanie „jak”. Odpowie za to na pytanie „dlaczego”, jakie są tego korzyści i z czym to się wiąże na dłuższą metę (bo przecież nie samą kostką człowiek żyje;)).
Zacznijmy od wyjaśnienia kwestii podstawowych - za bajery na pulpicie odpowiada menadżer okien. Tylko i wyłącznie. XGL oraz AIGLX to jedynie technologie umożliwiające realizację takich a nie innych założeń, podstawową ich cechą jest akceleracja wszystkich operacji, od rysowania okienek, po ich compositing (nakładanie na siebie aby stworzyć to co widzimy na pulpicie), poprzez OpenGL. Pozwala to na wykorzystanie w pełni możliwości współczesnych kart graficznych, które nastawione są przede wszystkim na wykonywanie skomplikowanych obliczeń odpowiedzialnych za tworzenie grafiki trójwymiarowej - podczas codziennej pracy, czy to przeglądając maile, czy to szukając czegoś w sieci, nie wykorzystujemy tych możliwości nawet w ułamku procenta. Ale czy to oznacza, że nadają się one tylko i wyłącznie do zaawansowanych gier? Nie. Zapoznajmy się więc bliżej z technologiami leżącymi u podstaw bajerów, na widok których użytkownicy pewnego systemu zielenieją z zazdrości;)
XGL - ta nazwa jest kojarzona jednoznacznie. look ma, CUBE! Niesłusznie. Z rzeczoną kostką łączy ją jedynie osoba dewelopera - Davida Revemana. XGL powstał jako proste i skuteczne rozwiązanie mające na celu umożliwienie akceleracji pulpitu przez OpenGL. Bez wdawania się w techniczne szczegóły - każda aplikacja wyświetla grafikę poprzez wydawanie poleceń serwerowi X - standardowo jest to Xorg. Logicznym więc wyjściem wydawało się „wpięcie się” pomiędzy przysłowiowy młotek a kowadło - przechwycenie operacji rysowania na ekranie i dzięki temu przyspieszenie całości. XGL był jedną z kart przetargowych SUSE Linux Enterprise Desktop 10 firmy Novell - wraz z menadżerem okien Compiz dawał przedsmak tego co jest możliwe dzisiaj. Bardzo szybko rozwiązanie to rozpowszechniło się na openSUSE (wówczas jeszcze SUSE 10.0), jednocześnie trafiając do dystrybucji nie związanych z Novellem - jak chociażby Ubuntu czy Gentoo. Z tego właśnie powodu po dziś dzień wiele osób słysząc „XGL” ma na myśli kostkę Compiza i wszelkie związane z nią bajery - mylące, ale takie są skutki bycia pierwszym na rynku.
Zalety:
- XGL jest niezależny od oprogramowania leżącego „pod spodem” - wymaga jedynie sprzętowej akceleracji 3D, więc zadziała bez problemu (teoretycznie) na większości dostępnych kart graficznych,
- jest instalowany standardowo w kilku dystrybucjach, wraz z odpowiednimi opcjami w panelu sterowania - chociażby w openSUSE.
Wady:
- XGL to pomost pośredni pomiędzy aplikacjami a faktycznym X-serwerem, co prowadzi do wielu nieprzewidzianych konsekwencji. Kłopoty z układem klawiatury, błędy wyświetlania aplikacji SDL, problemy z tunerami tv - to tylko niektóre z nich,
- aplikacje nie mają bezpośredniego dostępu do X-serwera leżącego „pod spodem”, a co za tym idzie - do akceleracji sprzętowej 3D. Wszystkie operacje wykonywane są za pośrednictwem XGL, co oczywiście wpływa negatywnie na wydajność - bywa to widoczne zwłaszcza w przypadku odtwarzania na pełnym ekranie filmów bądź grania w gry 3D.
Zszokowani? Otóż sprawa wygląda następująco - aby zadziałała akceleracja pulpitu poprzez OpenGL, wymagana jest dostępność pewnej funkcji - mianowicie texture_from_pixmap. Służy ona m.in. do zamieniania okienek, zapisanych w pamięci pod postacią bitmap, na tekstury, które następnie mogą być nakładane na obiekty 3D, z których składają się okienka menadżerów okien Compiz czy Beryl. Jak więc radzi sobie z tym XGL i dlaczego działa na kartach i sterownikach/X-serwerze, które tego rozszerzenia nie udostępniają? Otóż emuluje je w sposób programowy przy pomocy biblioteki MESA. Co za tym idzie, wszystkie odwołania do X-serwera, włącznie z akcelerowanymi operacjami 3D, muszą przejść przez XGL i jego metodę na obejście braku texture_from_pixmap, co skutkuje tym że np. uruchomiony pod XGL Quake III nie ma bezpośredniego dostępu do sprzętu - zamiast wyświetlać grafikę poprzez bibliotekę libGL akcelerowaną sprzętowo przez kartę graficzną, wyświetla ją poprzez bibliotekę libGL XGL-a, co określane jest mianem indirect rendering. Nie jest to oczywiście tak wolne jak zupełny brak akceleracji, ale jednak…
Skoro więc konieczne stało się rozwiązanie problemu wydajności, a jednocześnie aplikacje w środowisku menadżera okien 3D muszą działać poprzez indirect rendering - gdyż wyniki ich działania są za pośrednictwem texture_from_pixmap zamieniane na tekstury okienek, co dalej? Z pomocą przychodzi nam…
AIGLX - czyli Accelerated Indirect GLX. Rozwiązanie zaproponowane pierwotnie przez Redhata, rozwijane w ramach projektu Fedora Core, w dosyć krótkim czasie uzyskało poparcie firmy Nvidia - producenta kart graficznych, który od dobrych kilku lat wspiera Linuksa. W dużym skrócie - AIGLX jest integralną częścią X-serwera (dokładnie Xorg), co pozwala aplikacjom na korzystanie z pełnej akceleracji sprzętowej, z zachowaniem indirect rendering, a więc z zachowaniem możliwości manipulacji wyświetlanym obrazem poprzez menadżer okien 3D. Aplikacje mają bezpośredni dostęp do serwera Xorg, więc nie ma problemów z brakiem kompatybilności, jak chociażby w wypadku tunerów tv itd.
Zalety:
- większa wydajność i kompatybilność niż w przypadku XGL,
- znacznie lepsza obsługa starszych kart graficznych ATI oraz zintegrowanych chipsetów Intela poprzez sterowniki opensource - XGL działa na tych kartach znacznie wolniej,
- wsparcie firmy Nvidia - w przypadku najnowszych sterowników nie jest nawet konieczne włączenie AIGLX w konfiguracji Xorg - AIGLX jest wspierane natywnie przez sterowniki kart graficznych tej firmy.
Wady:
- w zasadzie jedna. Brak możliwości uruchomienia AIGLX na kartach ATI wyższych niż X850 - sterowniki opensource jeszcze tych modeli nie obsługują, a firma ATI niestety nie kwapi się z implementacją obsługi AIGLX w swoich sterownikach (a sprowadza się to do implementacji nieszczęsnego texture_from_pixmap, co jak pokazała Nvidia, nie jest żadnym problemem…). Ale użytkownicy Linuksa już niejednokrotnie przekonali się na własnej skórze, jak wygląda wsparcie firmy ATI dla naszego systemu.
Podsumowując - jeśli tylko sprzęt na to pozwala (karta graficzna inna niż najnowsze modele ATI) - AIGLX jest lepszym z tych 2 rozwiązań. XGL, pierwotnie jedyna metoda, pozostaje obecnie na placu boju jako zło konieczne dla użytkowników najnowszych kart ATI, a i to do czasu. Użytkownicy pozostałych kart, a Nvidii w szczególności, powinni się zdecydować na AIGLX - żadnych problemów z konfiguracją, znacznie większa kompatybilność i przede wszystkim wyższa wydajność to cechy w tym wypadku decydujące.
Tak więc mamy już wybrane jedno z rozwiązań umożliwiających odpalenie nowego menadżera okien 3D. Powstaje kolejne pytanie: Compiz czy Beryl?
Compiz - napisany przez Davida Revemana, wszelkie zmiany kodu dostarczane przez innych deweloperów są po dziś dzień przez Davida zatwierdzane. Bardzo restrykcyjna polityka dotycząca jakości stosowanych rozwiązań, co skutkuje momentami mniejszą ilością bajerów (na dzień dzisiejszy - brak pluginu blur - bezużyteczny, brak własnego dekoratora okien z obsługą zaawansowanych skórek - jest za to obsługa dekoracji natywnych gnome/kde), za to zdecydowanie większą stabilnością działania i generalnie większą płynnością/wydajnością.
Beryl - fork projektu Compiz, pierwotnie opracowany i po dziś dzień zarządzany przez QuinnStorm. Pierwotna nazwa - compiz-quinnstorm, po pewnym czasie została zmieniona na Beryl, w momencie kiedy QuinnStorm stwierdziła iż nie ma już drogi odwrotu i że należy się definitywnie odciąć od oryginalnego Compiza. Dlaczego? Compiz nastawiony jest na integrację z istniejącymi środowiskami (głównie gnome/kde), Beryl - stara się za wszelką cenę od nich uniezależnić, QuinnStorm wraz z resztą deweloperów usunęła zależności od bibliotek gnome, przepisała system zapisu konfiguracji na własny, niezależny od gconf, został również stworzony niezależny dekorator okien dla Beryla - Emerald (pierwotnie cgwd w compiz-quinnstorm), wszystko w celu odcięcia się od środowisk gnome/kde.
Pomiędzy środowiskami deweloperów tych dwóch środowisk brak jest współpracy, QuinnStorm zarzucała swego czasu Davidowi Revemanowi odrzucanie ich poprawek do kodu, prawda jednakże jest taka że poziom jakości kodu, jaki toleruje i zatwierdza QuinnStorm w przypadku Beryla, dosyć mocno odstaje od norm, którymi kieruje się David Reveman w przypadku Compiza. Nie była to więc niechęć do współpracy ze strony deweloperów Compiza, lecz raczej nieustanna pogoń za nowinkami pod postacią coraz to nowszych bajerów ze strony autorów Beryla. Nawet za cenę jakości i stabilności kodu. Ciekawostką jest fakt, że po dziś dzień twórcy Beryla wykorzystują w swej pracy coraz to nowsze fragmenty kodu Compiza, lecz w drugą stronę taka zależność nie funkcjonuje. Powód jest prozaiczny - Compiz jest na licencji MIT, natomiast Beryl - GPL, co Davidowi i reszcie deweloperów uniemożliwia wykorzystanie kodu Beryla we własnym projekcie. Różne są również sposoby współpracy poszczególnych grup - deweloperzy Compiza komunikują się poprzez listę mailową, a wszelkie poprawki są zatwierdzane przez Davida - to grupa doświadczonych programistów, pracujących w sporych firmach - David Reveman zatrudniony jest w firmie Novell, natomiast deweloperzy Beryla to grupa młodych ludzi komunikujących się głównie za pośrednictwem IRCa, a ich podstawową zasadą jest „zrobić coś, szybko i skutecznie, nieważne jak”. Początkowo Beryl (jeszcze za czasów compiz-quinnstorm) przewyższał swój pierwowzór ilością bajerów, czym narobił wokół siebie sporo szumu. Od tamtego czasu wiele osób zwyczajnie przestało się interesować Compizem, uważając Beryla za wygodniejsze i bardziej bajeranckie rozwiązanie. Nic bardziej mylnego. Compiz, nie licząc braku Emeralda (co częściowo nadrabia wsparciem dla dekoracji okien gnome/kde) czy pluginu blur, w niczym nie ustępuje Berylowi, a przewyższa go stabilnością i wydajnością działania. Nie bez powodu to właśnie Compiz jest instalowany domyślnie wraz z najnowszym openSUSE czy Fedorą - nawet użytkownicy Ubuntu, dystrybucji w której dopiero kolejna wersja przyniesie zainstalowany domyślnie menadżer okien 3D, wyrazili na swym forum nadzieję że będzie to Compiz. Pomimo iż głównie na tej właśnie dystrybucji Beryl jest rozwijany. Decyzja należy do was:)
Nawet jeśli nie bawi Cię kostka z wirtualnymi pulpitami, nawet jeśli nie masz ochoty na „gumowe” okienka - warto spróbować. Wszelkie bajery są pod postacią pluginów, można je w prosty sposób wyłączyć, a jednocześnie w dalszym ciągu korzystać z akceleracji pulpitu poprzez OpenGL. Wygoda pracy na takim rozwiązaniu jest nieporównywalna z czymkolwiek innym - żadne środowisko graficzne nie korzystające ze sprzętowej akceleracji 3D nie może się z tym równać jeśli chodzi o płynność i wydajność działania. Nie zapominajmy jednakże o jednym - menadżery okien są w dalszym ciągu w fazie beta. Zapewne instalując chociażby Compiza, pokusicie się o najnowszą wersję testową - ale warto się czasem zastanowić nad zainstalowaniem nieco starszej, stabilnej wersji. Nie dlatego że testowa jest niestabilna - działa zaskakująco dobrze. Ale choćby dlatego by mieć pewność, że żadnych problemów ze stabilnością mieć nie będziemy. Kwestia wyboru pomiędzy najnowszymi bajerami a w 100% stabilnym środowiskiem pracy - w razie gdyby błąd pojawiający się znienacka raz na tydzień bądź raz na miesiąc miał was zniechęcić. Trzeba być świadomym tego, że to technologia rozwojowa… choć i tak wszyscy wiemy, co zrobicie;)
Przedstawione w powyższym artykule opinie są prywatnymi opiniami autora - w razie wątpliwości zapraszam do polemiki - unic0rn@irc.freenode.net.
Źródło: openSUSE polish wiki