Zazwyczaj nowe, wysokobudżetowe gry komputerowe zachwycają nas niezwykle piękną grafiką. Aby również móc się nią cieszyć, użytkownicy Linuksa wybierają takie karty graficzne, które są zdolne do obsługi najnowszej wersji OpenGL w możliwie najwydajniejszy sposób. Podczas codziennej pracy (zwłaszcza gdy nie korzysta się z Unity lub GNOME-Shell) akceleracja 3D nie ma jednak tak dużego znaczenia, za to bardzo ważna okazuje się akceleracja 2D. To, czy przeglądarka internetowa będzie się „przycinać” podczas przewijania strony; to, czy klient poczty szybko pokaże nam wszystkie obrazki w e-mailu, nie zamrażając jednocześnie komputera nawet na moment – to wszystko zależy od jakości akceleracji wyświetlania grafiki 2D.
W niniejszym artykule opowiem o historii rozwoju akceleracji 2D.

1. Powstanie X-serwera.

W latach 80-tych XX wieku powstał X Window System, który pozwolił w Uniksach korzystać nie tylko z konsoli tekstowej, ale również ze środowiska graficznego. Dzięki temu wynalazkowi wreszcie można było używać myszy komputerowej, co znacząco podnosiło wydajność pracy. Ponadto serwer wyświetlania grafiki umożliwił wygodne przeglądanie zdjęć, oglądanie filmów, a także korzystanie z aplikacji graficznych. Środowiska graficzne nie tylko zwiększały funkcjonalność systemów operacyjnych, ale również – dzięki projektowaniu z uwzględnieniem estetyki – poprawiały ich wygląd. W miarę upływu czasu operacje związane z wyświetlaniem grafiki stawały się więc coraz bardziej intensywne. Ponieważ w latach 80-tych koncepcja dodatkowego układu do obliczeń związanych wyłącznie z grafiką była jeszcze w powijakach, to X-serwer jej nie uwzględniał i wszelkie obliczenia były przeprowadzane jedynie na głównym procesorze. Konieczność wykonywania w tym samym czasie obliczeń związanych z pracą aplikacji i wyświetlaniem grafiki okazała się jednak wkrótce zbyt dużym obciążeniem dla procesora. Aby go odciążyć, do protokołu X zaczęto wprowadzać kod pozwalający do akceleracji 2D wykorzystać układy graficzne.

2. XAA

W 1996 roku po raz pierwszy wprowadzono do X-serwera metodę akceleracji 2D nazwaną XAA (akronim XFree86 Acceleration Architecture). Działa ona w ten sposób, że polecenia renderowania, które wcześniej były przekazywane do buforu ramki, są przechwytywane przez sterownik karty graficznej. Sterownik pozwala na wykorzystanie akceleracji do rysowania prostych elementów, takich jak linie, czy wypełnianie barwami. Bardziej złożone zadania rozbijane są na prostsze, które mogą zostać przetworzone przez kartę graficzną, a w przypadku braków sprzętowych lub ograniczeń sterownika przekazywane są do procesora do obróbki programowej. Technologia szybko upowszechniła się wśród otwartych sterowników do X-serwera i pozwoliła wreszcie na uwolnienie głównego procesora od części pracy związanej z grafiką. Jednak w miarę upowszechniania XAA zaczęły się ujawniać wady tego rozwiązania, w praktyce bardzo skomplikowanego. Coraz częściej – czy to na skutek błędów w sterowniku, czy w samym sprzęcie – dochodziło do „wykrzaczania” się X-serwera. Jeżeli awaria związana była chociażby z oprogramowaniem Qt lub GTK+, to był to już naprawdę poważny problem. Do czasu usunięcia błędu, jako prowizoryczne rozwiązanie, stosowano blokowanie przetwarzania niepoprawnie działających funkcji, co w konsekwencji oznaczało konieczność wyświetlania części obrazu bez przyspieszenia sprzętowego. Ponadto okazało się, że z powodu przyjętej metody akceleracji moc obliczeniowa karty graficznej jest intensywnie wykorzystywana i to często na operacje niemające dużego znaczenia dla użytkownika. W 2000 roku wprowadzono do X-serwera rozszerzenie XRender (zwane też powszechnie po prostu RENDER), pozwalające na wyświetlanie bardziej złożonego obrazu, który nie mógł być wcześniej generowany lub jego rysowanie było bardzo mało wydajne obliczeniowo (antyaliasing, kanał alfa, skalowanie czcionek). RENDER dostarczał bardzo wygodny interfejs dla programów, a jednocześnie zapewniał nowoczesny wygląd. Główne biblioteki odpowiedzialne za generowanie obrazu (GTK+, Qt, Cairo) szybko zaczęły migrować na nową technologię. Powstał też nowy typ menadżerów okien oparty o RENDER, zwanych kompozytorami – wkrótce zastosowano je w środowiskach graficznych GNOME i KDE. W konsekwencji RENDER stał się odpowiedzialny za rysowanie na ekranie niemalże wszystkiego, co nie korzystało z OpenGL. W związku z tym w zamkniętych sterownikach do kart graficznych zaczęto korzystać do akceleracji 2D tylko z niego. Także otwarte XAA próbowano dostosować tak, by mogło przetwarzać wywołania RENDER-a, ale nie odniesiono na tym polu większych sukcesów.

3. EXA i UXA

Ostatecznie okazało się, że XAA ma więcej wad, niż zalet. Nie dość, że silnie obciążało kartę graficzną, to jeszcze nie było w stanie zapewnić akceleracji dla większości operacji związanych z rysowaniem grafiki. W związku z tym w 2005 roku zaprezentowano nową metodę akceleracji 2D, nazwaną EXA. Została ona zaprojektowana specjalnie z myślą o akceleracji wszelkich wywołań RENDER. Wszystkie stare metody akceleracji postanowiono porzucić, dzięki czemu sam sterownik i jego interfejs stałyby się proste i niezawodne. Następnie do jądra systemu Linux wprowadzono mechanizmy TTM (Translation Table Maps) – zaawansowaną formę zarządzania pamięcią przez otwarte sterowniki do kart graficznych. EXA została szybko przystosowana do korzystania z tej technologii. Tę metodę akceleracji zaadaptowano w sterownikach radeon i nv (a później nouveau), co nareszcie pozwoliło na niezawodną i sprawną akcelerację 2D wszystkich wyświetlanych elementów. Niestety, dla Intela oznaczało to kłopoty. W owych czasach ta firma produkowała bardzo słabe układy graficzne. EXA pozwalała na akcelerację wszystkiego, ale mało wydajna grafika powodowała przycinanie się obrazu na ekranie. Ostatecznie Intel sforkował EXA do swojego projektu UXA. Wprowadził też do jądra Linuksa własne mechanizmy zarządzania pamięcią układów graficznych GEM (Graphics Execution Manager) i silnie od nich uzależnił UXA. Nie przyniosło to jednak oczekiwanych rezultatów. Przejście z XAA na UXA wiązało się dla użytkowników układów graficznych Intela z silnie odczuwalnym obniżeniem płynności ich działania. Z biegiem czasu Intel zaczął jednak produkować lepsze grafiki, a UXA i GEM także zostały zoptymalizowane, co w konsekwencji przywróciło płynność wyświetlania środowiska graficznego, a jednocześnie zapewniało pełną akcelerację 2D. Ostatecznie XAA zostało usunięte całkowicie z X-serwera w wersji 1.13 w 2012 roku.
Nie ulega wątpliwości, że twórcy współczesnych kart graficznych skupiają się na ich wydajności 3D, zaniedbując akcelerację 2D. W końcu to zazwyczaj 3D jest wąskim gardłem dla najnowszych gier komputerowych. Z tego powodu wydajność akceleracji 3D wzrosła niewspółmiernie w porównaniu do 2D, która od lat nie ulega większym zmianom. Nie minęło wiele czasu, gdy środowiska graficzne zaczęły korzystać do zapewnienia ciekawych wizualnie efektów właśnie z akceleracji 3D (poprzez OpenGL). Taką sytuację mamy w Unity, GNOME Shell, a opcjonalnie nawet w KDE. W rezultacie nawet w gronie deweloperów sterowników do kart graficznych zaczęły pojawiać się pomysły, żeby całą akcelerację 2D przetwarzać przy pomocy 3D.

4. SNA i GLAMOR

Wykorzystanie układu karty graficznej odpowiedzialnego za akcelerację 2D nie zawsze musi być opłacalne. Akceleracja 3D jest dużo szybsza i gdyby udało się dostosować sterowniki tak, by wykorzystywały możliwości 3D karty graficznej do akceleracji 2D, to zapewne zyskałoby się na wydajności. Należy tu wspomnieć o pionierskim rozwiązaniu, jakim było rozszerzenie możliwości Gallium3D o obsługę X-serwera (Xorg state tracker). Projekt ten jednak nigdy nie został ukończony i niemal w ogóle nie używano go w praktyce. Ostatecznie został usunięty z Gallium3D na rzecz innych rozwiązań. Niedługo później światło dzienne ujrzały dwa konkurencyjne projekty Intela – GLAMOR i SNA. Ten pierwszy to dodatkowa biblioteka systemowa. Przechwytuje ona wszystkie operacje 2D, które mają być przetwarzane przez grafikę, a następnie zamienia je na wywołania mogące być przyspieszane przy pomocy sterownika 3D. Dzięki temu zanika potrzeba rozwijania oddzielnych sterowników do 2D i 3D, a więcej zasobów można przerzucić na rozwój samego OpenGL. SNA to metoda akceleracji silnie i bezpośrednio związana z układami graficznymi Intela. Nastawiona jest na optymalizację specyficzną dla sprzętu. Tam, gdzie przynosi to korzyści, grafika 2D jest przetwarzana przez układ 3D, zaś tam, gdzie byłoby to skomplikowane lub nieefektywne, dalej jest wykorzystywana tradycyjna akceleracja. Już pierwsze testy wykazały, że SNA jest wyraźnie wydajniejsza, w związku z tym Intel rozpoczął proces migracji z UXA na SNA. GLAMOR jednak nie odszedł w niepamięć. Został zaadaptowany przez deweloperów otwartych sterowników do układów AMD i jest wykorzystywany jako jedyna metoda akceleracji 2D dla układów Radeon HD 7000 i nowszych, a także zostanie dostosowany tak, by mogły opcjonalnie z niego korzystać również starsze karty graficzne.

5. Podsumowanie

Akceleracja 2D w Linuksie przeszła ciekawą drogę. Od zupełnego jej braku, przez różne techniki wykorzystywania możliwości kart graficznych, aż po zupełne zastępowanie jej przez akcelerację OpenGL. Nie ulega wątpliwości, że akceleracja 2D ma duży wpływ na codzienną pracę przy komputerze. Związanie jej z bardzo dużymi możliwościami 3D współczesnych kart graficznych powinno zaowocować wydajniejszymi środowiskami graficznymi, a jednocześnie zapewnić ładniejsze efekty pulpitu.

korekta: ionash