Drzemiące megaflopy
Powstała koncepcja GPGPU, czyli General Purpose Graphics Processing Unit. „Jednostka przetwarzania grafiki ogólnego zastosowania” brzmi bez sensu – w końcu służy do grafiki czy do ogólnych zastosowań? Okazuje się, że programowalne jednostki obliczeniowe nowoczesnych GPU mogą służyć i do tego, i do tego.
W tym miejscu musimy się zastanowić, jak programy korzystają z układów graficznych. Procesor to jasna sprawa: ktoś pisze kod, a system operacyjny dba o jego prawidłowe wykonanie równocześnie z setkami innych fragmentów kodu. Ale karta graficzna nie jest bezpośrednio programowalna, nie jest po prostu dodatkową jednostką wykonawczą procesora. Jej pamięć nie jest częścią przestrzeni adresowej „głównej” pamięci operacyjnej komputera – nie wpisuje się bezpośrednio do niej kodu i instrukcji. Pośredniczy w tym sterownik, udostępniający różne interfejsy programowania, czyli sposoby odwoływania się do karty. Takimi interfejsami są na przykład DirectX i OpenGL.
Wraz z rozwojem sprzętu, o którym wspomnieliśmy w pierwszym akapicie, następował rozwój wspomnianych interfejsów. Najbardziej znane i najczęściej wykorzystywane to:
- DirectX – to cały zbiór różnych interfejsów programistycznych, z których karty graficznej dotyczą: DirectDraw, Direct 2D (oba używane do wyświetlania grafiki dwuwymiarowej), Direct3D (wyspecjalizowany w wyświetlaniu grafiki trójwymiarowej, wykorzystywany przez większość gier) i DirectCompute (do wykonywania obliczeń na GPU). DirectX jest ściśle związany z systemem Windows. Od dawna stosuje się go nie tylko w grach: na przykład wiele programów odtwarzających filmy wyświetla obraz z użyciem DirectDraw.
- OpenGL – główny rywal DirectX, o bardzo podobnej funkcjonalności. Jest otwartym standardem nieprzywiązanym do żadnego systemu operacyjnego. Wykorzystują go niektóre gry, szczególnie te dostępne na Linuksa lub Mac OS X. Oprócz tego jest powszechnie stosowany do wyświetlania grafiki dwu- i trójwymiarowej w profesjonalnych narzędziach, takich jak produkty Adobe i Autodesk.
- CUDA – interfejs programowania kart graficznych Nvidii służący do wykonywania obliczeń. Jest dostępny w wersjach dla Windows, Linuksa i Mac OS X, ale to standard zamknięty, ograniczony do układów Nvidii. Wykorzystywany głównie w przemyśle i badaniach naukowych, a tam i tak używa się oprogramowania dostosowanego do konkretnych maszyn.
- OpenCL – interfejs programowania wyspecjalizowany w obliczeniach, nie tylko wykonywanych z użyciem procesorów graficznych. Pozwala jednakowo potraktować wszystkie urządzenia obliczeniowe w komputerze: procesor, GPU, a nawet różnego rodzaju procesory sygnałowe.
- DXVA, XVBA, XVMC, VA-API, OpenVideo Decode, VDPAU, Intel ClearVideo, Intel QuickSync – cała gama interfejsów programistycznych dających dostęp do wbudowanych w układy graficzne wąsko wyspecjalizowanych jednostek kodowania i dekodowania wideo. Karty AMD mają dekoder UVD i koder VCE, Intel ma ClearVideo i QuickSync, Nvidia – PureVideo; są to jednak wyspecjalizowane jednostki wbudowane w krzem. Są one w mniejszym lub większym zakresie programowalne, ale mogą służyć tylko do obróbki wideo – nie można powiedzieć, że są ogólnego zastosowania.
W tym artykule przyjrzymy się temu przedostatniemu, OpenCL, a szczególnie wykorzystaniu go w programach użytkowych, z którymi domowy użytkownik może się zetknąć na co dzień.
Jaki trzeba mieć sprzęt i jakie oprogramowanie?
Jak powiedzieliśmy, wszystkie wymienione interfejsy programowania wymagają odpowiedniego sterownika. OpenCL jest obsługiwany przez następujące układy graficzne AMD:
- z serii HD 4000, oprócz zintegrowanych z serii HD 4200;
- wszystkie z serii HD 5000, HD 6000, HD 7000;
i te oto układy Nvidii:
- wszystkie z serii GeForce 8000, 9000, łącznie ze zintegrowanymi;
- wszystkie z serii 200, 300, 400, 500, 600;
a także zintegrowane GPU Intela – tylko HD Graphics 4000 i 2500, wbudowane w procesory Core trzeciej generacji (22-nanometrowe Ivy Bridge).
Ale OpenCL nie jest ograniczony do układów graficznych – w założeniu ma korzystać z dowolnych urządzeń obliczeniowych obecnych w komputerze. Sterowniki do kart AMD instalują zatem oddzielny sterownik procesora zgodny z OpenCL; pozwala on potraktować dowolny procesor z instrukcjami SSE2 jako urządzenie OpenCL. Intel udostępnia OpenCL SDK, zestaw narzędzi programistycznych zawierający sterownik OpenCL do każdego układu z SSE4.1 (zobacz listę). Jeśli masz kartę graficzną Nvidii, a chcesz zaprząc swój sprzęt do obliczeń OpenCL, musisz zainstalować SDK Intela lub AMD wraz z odpowiednim sterownikiem procesora.
Przy instalowaniu sterowników trzeba pamiętać, żeby wybrać wersję zawierającą biblioteki OpenCL. Z kartami Nvidii nie ma tego problemu – obsługa OpenCL jest częścią funkcjonalności platformy CUDA, więc firma nie udostępnia sterowników bez OpenCL. AMD też oferuje do pobrania już tylko pakiety ze sterownikiem OpenCL. Domyślnie instalowany jest pełen pakiet, łącznie ze sterownikiem OpenCL, ale wybierając własne opcje instalacji, można usunąć jego zaznaczenie (pozycja AMD APP SDK), czego oczywiście nie polecamy. Sterowniki do najnowszych GPU Intela również zawierają biblioteki OpenCL. Ze strony Intel OpenCL SDK można też pobrać same biblioteki OpenCL (pozycja CPU only runtime package).
Czy w swoim komputerze mogę wykorzystać OpenCL?
Łatwo to sprawdzić, wiele programów diagnostycznych wyświetla potrzebne informacje. Najwygodniej będzie użyć popularnego GPU-Z:
Przytrzymanie wskaźnika myszy nad ptaszkiem „OpenCL” wyświetla dodatkową informację o najwyższej obsługiwanej wersji tego standardu. Niestety, GPU-Z pokazuje tylko dane dotyczące obsługi obliczeń z użyciem GPU, a przecież OpenCL z założenia nie jest ograniczony do konkretnego typu urządzeń. By obejrzeć bardziej dokładne informacje, trzeba użyć darmowego programu GPU Caps Viewer:
W nim, na samej górze zakładki OpenCL, można się dowiedzieć, ile „platform” OpenCL jest zainstalowanych na komputerze. W systemie jest obecny tylko sterownik Intela obsługujący dwa urządzenia OpenCL: procesor (cztery rdzenie Core i3-3225) oraz jego rdzeń graficzny (Intel HD Graphics 4000).
W systemach Linux można zobaczyć listę zainstalowanych platform OpenCL, wywołując polecenie $ ls /etc/OpenCL/vendors.
OpenCL w programach użytkowych
Odkąd urządzenia zaczęły obsługiwać OpenCL, ich producenci starają się wspierać twórców oprogramowania w stosowaniu tego standardu i oczywiście reklamować nowe funkcje. Przyjrzeliśmy się programom użytkowym (nie naukowym ani programistycznym!), szczególnie tym popularnym i tym, które są mniej znane, ale bardzo promowane przez producentów. Największym popularyzatorem wiedzy o OpenCL jest AMD, co nie powinno nikogo dziwić. Nvidia woli bowiem promować swój zamknięty standard CUDA, a urządzenia Intela dopiero od niedawna obsługują OpenCL, przy czym ich moc obliczeniowa jest stosunkowo skromna.
Adobe Photoshop. Wersje Photoshopa starsze niż CS4 nie wykorzystują karty graficznej w żaden sposób. Photoshop CS4 oraz CS5 stosują OpenGL do wyświetlania obszaru roboczego. Wymagana jest karta obsługująca OpenGL 2.0 i Shader Model 3.0, który to warunek spełniają niemal wszystkie wyprodukowane po 2005 roku (z wyjątkiem niektórych zintegrowanych GPU). Użycie OpenGL pozwala na takie operacje, jak płynne przybliżanie, przesuwanie i obracanie czy szybkie konwertowanie kolorów. Nie licząc konwersji kolorów, wszystkie te funkcje dotyczą tylko wyświetlania – końcowa obróbka jest wykonywana wyłącznie programowo, przez główny procesor. W najnowszej wersji, CS6, wprowadzono nowy silnik graficzny, w większym stopniu wykorzystujący GPU. Całą listę nowych możliwości można znaleźć na stronie pomocy technicznej, ale najważniejsze z nich to przekształcenia geometryczne z użyciem OpenGL oraz trzy filtry rozmycia z zastosowaniem OpenCL (Rozmycie pola, Rozmycie przesłony i Tilt-Shift). Obsługa OpenCL powinna być automatycznie włączona, ale zdarza się, że Photoshop niewłaściwie wykrywa obecny w komputerze układ graficzny. Wtedy trzeba ją ręcznie włączyć:
Dzięki OpenCL trzy wspomniane filtry rzeczywiście są przeliczane szybciej, lecz aby w codziennej pracy zauważyć różnicę, trzeba obrabiać pliki większe niż te pochodzące z popularnych, kilkumegapikselowych lustrzanek. Wydaje się, że wykorzystanie OpenCL w trzech filtrach w tak bogatym w funkcje programie to na razie eksperyment. Do całej masy innych operacji można by użyć GPU – wciąż czekamy na wersję Photoshopa, w której narzędzie Smużenie o dowolnym rozmiarze pędzla będzie działać bez żadnego opóźnienia.
darktable. To linuksowy program do obróbki zdjęć, szczególnie cyfrowych negatywów. Większość operacji korzysta ze wspomagania GPU, ale niewiele jest zauważalnie szybszych. W typowej obróbce, podczas której na przemian wydaje się kolejne polecenia i obserwuje efekt na ekranie, większość zmian następuje bardzo szybko nawet bez użycia OpenCL. Za to podczas zaskryptowanego przetwarzania obrazów można osiągnąć dzięki niemu kilkukrotne przyspieszenie. Uwaga – obsługa OpenCL jest domyślnie wyłączona!
GIMP. To popularny zamiennik Photoshopa, bezpłatny program do edycji grafiki dostępny w wersjach na wszystkie większe systemy operacyjne. GIMP jest w tej chwili w trakcie „przesiadki” ze starego silnika na nowy – bibliotekę graficzną GEGL, wykorzystującą akcelerację OpenCL. Co to znaczy? Najnowsza wersja GIMP-a, 2.8.2, używa starego silnika do wszystkich standardowych operacji. W menu programu można znaleźć listę GEGL Operations, czyli operacji wykonywanych za pomocą nowego silnika; są wśród nich głównie intensywne obliczeniowo filtry, takie jak rozmycie Gaussa. W praktyce akcelerowanych przez OpenCL operacji jest jeszcze niewiele i rzadko się je stosuje. Na stronie GIMP-a można przeczytać, że twórcy programu chcieliby skończyć przesiadkę na GEGL w 2013 roku, ale się obawiają, że może to potrwać dłużej. Na razie akceleracja GPU pozostaje w tym programie raczej ciekawostką.
Mathematica 9. Znany „kombajn” matematyczny pozwala korzystać z urządzeń OpenCL z poziomu wewnętrznego języka programowania. Zapewniający podobną funkcjonalność plugin do MATLAB-a był dostępny jeszcze do niedawna, ale został sprzedany twórcom MATLAB-a, firmie MathWorks, która ograniczyła funkcjonalność do obsługi CUDA.
Test – Luxmark, CLBenchmark
Testy zaczęliśmy od dwóch programów, co do których mamy pewność, że dobrze się skalują z dostępną mocą obliczeniową, a OpenCL prawidłowo w nich działa. Pierwszy to typowy benchmark syntetyczny CLBenchmark. Wybraliśmy z niego trzy operacje najbardziej zbliżone do praktycznych zastosowań: symulację fizyki cieczy (już dziś można to spotkać w grach, np. Borderlands 2), odnajdywanie krawędzi na obrazie (powszechne w komputerowym rozpoznawaniu kształtów) oraz rozmycie Gaussa.
CLBenchmark nie używa wszystkich dostępnych w komputerze urządzeń OpenCL: wybiera tylko jedno, domyślnie najszybsze, ale można zmienić wybór ręcznie. W wynikach prawie nic nas nie zaskakuje. HD Graphics 2500 jest o połowę wolniejszy od mającego dużo więcej (16 zamiast 6) jednostek obliczeniowych HD 4000. W przypadku zintegrowanych GPU Intela jeden z testów powodował zawieszanie się programu, do czego wkrótce się przyzwyczaimy :) Dziwią tylko duże różnice między HD 7850 a GTX 660. Kepler w tym wydaniu nie jest demonem GPGPU, ale maksymalna teoretyczna moc obliczeniowa sugeruje, że nie powinien być aż o tyle wolniejszy. To dowodzi, że algorytm i jego konkretna implementacja mają ogromny wpływ na wydajność, często większy niż czysta moc obliczeniowa sprzętu.
Luxmark zasługuje chyba na największy szacunek spośród wszystkich programów z „mark” w nazwie. Nie jest to typowy syntetyczny test oderwany od rzeczywistości – to symulacja renderowania scen 3D z użyciem silnika LuxRender. Podobne rezultaty powinniśmy osiągnąć, po prostu podłączając LuxRender do któregoś z programów do modelowania 3D.
Luxmark jest jednym z niewielu narzędzi, które potrafią skorzystać ze wszystkich urządzeń OpenCL do wykonywania jednego zadania. I nic dziwnego, przecież śledzenie promieni daje się bardzo dobrze zrównoleglić; każdy promień można śledzić osobno, a wyniki pośrednie nie są od siebie nawzajem zależne.
W przypadku Core i3 i zintegrowanych GPU Intela skalowanie jest bardzo dobre: choć wydajność GPU jest bardzo niska, to przyspieszenie po użyciu obu urządzeń OpenCL jest wyraźne. Sam procesor z układu A10-5800K jest mniej więcej równie wydajny jak sam wbudowany Radeon HD 7660D albo Core i3 do spółki ze swoim GPU. Za to przy wykorzystaniu jednocześnie CPU i GPU do renderowania wydajność jest mniejsza od sumy wydajności obu komponentów oddzielnie. Dlaczego? APU mają wbudowany dość skomplikowany mechanizm zarządzania energią, który przy obciążeniu obu części układu pilnuje, aby suma pobieranych prądów i wydzielanych mocy nie przekroczyła zadanych limitów. Inaczej mówiąc, obie części APU dzielą się zasobami energetycznymi, których nie wystarcza do tego, żeby oba komponenty działały na sto procent (przekroczyłyby limit cieplny i prądowy). Jak się wkrótce okaże, skierowanie zadań obliczeniowych do odpowiedniego urządzenia OpenCL jest kluczowe dla osiągnięcia dobrej wydajności.
Luxmark ma rzadko spotykaną wśród programów OpenCL funkcję: pozwala wybrać dowolną kombinację urządzeń OpenCL do przetestowania. Ponieważ na swojej maszynie testowej w pewnym momencie mieliśmy zainstalowane jednocześnie sterowniki Intela i AMD, postanowiliśmy sprawdzić, co się stanie, jeśli zlecimy obsługę procesora i3-3225 jako urządzenia OpenCL sterownikowi procesora dostarczonemu przez AMD. Ta konfiguracja działa, oczywiście, bez zarzutu, ale co najdziwniejsze...
...procesor Intela jest znacznie lepszym urządzeniem OpenCL, kiedy pracuje pod kontrolą sterownika AMD! Na pierwszy rzut oka wydaje się to dziwne, ale pamiętajmy, że AMD rozwija swój sterownik OpenCL od ładnych paru lat, a dla Intela jest to wciąż pewna nowość. To wyraźnie pokazuje, że choć standard OpenCL jest dobrze zaprojektowany, to jego konkretnym implementacjom daleko do doskonałości. Na szczęście CPU rzadko będzie wykorzystywany jako urządzenie OpenCL, bo jeśli obliczenia mają być prowadzone z użyciem procesora, to odpowiednio zoptymalizowany standardowy kod na ogół będzie szybszy i łatwiejszy do napisania.
Test – WinZIP
Według zapewnień twórców programu ten popularny archiwizer począwszy od wersji 16.5 wykorzystuje OpenCL do kompresji plików. Jest to płatne narzędzie, a wersja demonstracyjna działa tylko 21 dni. Po zainstalowaniu obsługa OpenCL jest domyślnie wyłączona, nawet jeśli system obsługuje OpenCL. Trzeba ją uaktywnić w opcjach programu:
Oficjalnie wspomaganie GPU jest obsługiwane tylko na komputerach z kartą graficzną AMD, wliczając w to układy zintegrowane w APU. Nic nie stoi jednak na przeszkodzie, żeby włączyć odpowiednią opcję na komputerze z inną kartą.
W teście WinZIP kompresowaliśmy paczkę 214 plików o łącznym rozmiarze ponad 800 MB, zawierającą krótkie klipy wideo, programy, zdjęcia w formacie RAW i dokumenty PDF.
Jak się okazuje, rodzaj użytego procesora graficznego, a nawet włączenie lub wyłączenie OpenCL nie robią najmniejszej różnicy. Ten sam wynik powtórzył się przy kompresowaniu innej paczki plików oraz po zastosowaniu innych metod kompresji. Czy akceleracja OpenCL w ogóle działa? Wzięliśmy większą paczkę plików i sięgnęliśmy po starszą wersję WinZIP-a, pierwszą, w której wprowadzono obsługę tej techniki:
Okazuje się, że w wersji 16.5 przełącznik obsługi OpenCL w opcjach programu działa... ale niezależnie od ustawienia użycie GPU wynosi 0%. Wersja 17 bez względu na konfigurację jest tak samo szybka jak 16.5 z włączonym OpenCL. Jak to wyjaśnić? Jedno z możliwych wytłumaczeń jest takie, że gdzieś między wersją 16 a 17 programiści WinZIP-a zaczęli w większym stopniu wykorzystywać wielowątkowość. Rzeczywiście, wersja 16.5 z OpenCL oraz 17 tworzyły więcej wątków, choć procentowe użycie procesora pozostawało podobne. W wersji 16.5 wielowątkowa architektura była dostępna przez OpenCL, a w następnej usprawnienia prawdopodobnie trafiły też do tradycyjnych algorytmów. Wszystkie opcje produkowały plik mniej więcej takiej samej wielkości: z paczki 1941 MB powstało archiwum o rozmiarze 1564 MB.
Ale czy WinZIP jest dobrym przykładem przyrostu wydajności płynącego z zastosowania OpenCL? Okazało się, że najnowszy 7-Zip tworzy z tych samych plików nieco mniejsze archiwum (1558 MB) w niemal dwa razy krótszym czasie, a do tego jest darmowy... Akcelerację GPU w WinZIP-ie musimy na razie potraktować jako eksperyment, w dodatku niezbyt dla nas zrozumiały.
Test – Handbrake oraz x264
Handbrake to popularny darmowy program do konwertowania wideo. Był jednym z pierwszych narzędzi, które AMD udostępniło dziennikarzom jako przykład zastosowania OpenCL. Wykorzystuje kod programu x264, ale w odróżnieniu od niego ma wygodny interfejs graficzny, więc nie trzeba używać wiersza poleceń. x264 jest wbudowany w każdą kompilację Handbrake, co znaczy, że nie można podmienić samego kodera x264, jeśli pojawi się jego nowa wersja. Handbrake ma otwarty kod, więc można zrobić własną kompilację.
Częścią procesu kodowania w programie x264 jest funkcja lookahead – przeglądanie kolejnych klatek filmu i sprawdzanie, jak bardzo się różnią od tej właśnie kodowanej. W ten sposób każda klatka jest kodowana inaczej w zależności od tego, co będzie w następnych – żeby obraz wyglądał dobrze w ruchu, a nie tylko zatrzymany. Tę część obliczeń oficjalne kompilacje x264 wykonują z użyciem procesora, w oddzielnym wątku, a AMD przeniosło ją na GPU. Według głównego dewelopera x264 lookahead stanowi 10–25% całego czasu trwania procesu kompresji, zatem w idealnym przypadku tylko o tyle można byłoby skrócić całkowity czas kodowania filmu. Warto zwrócić uwagę, że GPU wykonuje na tym etapie inny algorytm niż CPU. To powoduje, że wyniki teoretycznie nie są identyczne, choć nam nie udało się dostrzec różnicy nawet na zatrzymanych klatkach. Można by też zastosować bardziej skomplikowany algorytm lookahead, który dzięki wykorzystaniu GPU działałby z taką samą prędkością jak wersja CPU, ale zapewniał lepszą jakość obrazu. Bez wątpienia jest tu duże pole do poprawy.
Kompilacja Handbrake stworzona przez programistów AMD była ich niezależnym dziełem i nie była związana z deweloperami Handbrake. Publiczne kompilacje z oficjalnej strony nie obsługują OpenCL. Jeden z autorów programu na forum pomocy technicznej zapowiedział, że oficjalna obsługa OpenCL pojawi się zapewne w ciągu kilku miesięcy. Podobnie w samym koderze x264: odpowiednia łatka jest dostępna i można zrobić własną kompilację, ale na wykorzystanie OpenCL w oficjalnych trzeba jeszcze poczekać, nie wiadomo jak długo. Ciekawi mogą pobrać kompilacje testowe x264 z OpenCL oraz testową wersję Handbrake:
- x264 z akceleracją OpenCL – kompilacja testowa – blog Astrataro;
- Handbrake z akceleracją OpenCL – kompilacja testowa – pliki.onet.pl
Testowy Handbrake jest zgodny ze specyfikacją OpenCL, więc powinien działać na dowolnych urządzeniach, ale był testowany tylko w konfiguracjach z kartami AMD. Nam nie udało się go uruchomić z użyciem zintegrowanych GPU Intela.
W teście Handbrake kodujemy zwiastun filmu w rozdzielczości 1080p, używając predefiniowanych ustawień Android Mid, które powinny dać film zoptymalizowany pod kątem mniej wydajnych smartfonów z Androidem.
Gdy próbowaliśmy zaprząc do pracy zintegrowane układy graficzne Intela, testowa kompilacja Handbrake zawieszała się na samym początku kompresji. Maszyna z procesorem Core i5-3570K była tak samo szybka bez udziału GPU jak z wykorzystaniem Radeona HD 7850 lub GeForce'a GTX 660. Użycie GPU było bardzo niskie i występowało tylko przez kilka sekund na początku procesu kodowania. A10-5800K oraz oba Core i3 bez OpenCL były tak samo wydajne, ale APU zyskało kilka sekund na włączeniu OpenCL. Dziesięcioprocentowy zysk na operacji trwającej 30 sekund to niedużo, ale kodowaliśmy krótki film w mało wymagających ustawieniach, co nie jest wyzwaniem dla nowoczesnych komputerów.
Chcąc ocenić, jakie są zyski w bardziej wymagających zadaniach i czy nowe wersje x264 lepiej sobie radzą z wykorzystaniem GPU, sprawdziliśmy testową kompilację najnowszego kodera x264 w bardziej wymagających ustawieniach:
Jak widać, w pierwszym przejściu możliwa jest ogromna poprawa osiągów: maszyna z Core i5-3570K na tym etapie kodowania przyspieszyła o 50%, a z Radeonem HD 7850 – o jedną czwartą. W przypadku zintegrowanych GPU Intela włączenie OpenCL powodowało niekontrolowane zawieszanie się programu. Za to APU po włączeniu OpenCL wyraźnie zwolniło. Pamiętajmy, że w APU rdzenie procesora i układ graficzny dzielą się „budżetem” energetycznym. Włączenie akceleracji GPU w tym przypadku spowodowało takie spowolnienie CPU, że zysk z obliczeń przy użyciu GPU został utracony. W znacznie prostszym zadaniu wykonywanym za pośrednictwem Handbrake nie było tego problemu. W kodowaniu x264 dużo zależy od ustawień: im wyższa pożądana jakość obrazu i im szybszy procesor, tym większą korzyść da wykorzystanie OpenCL do kodowania.
Podsumowanie
Tych kilka testów powiedziało nam więcej na temat oprogramowania i samej platformy OpenCL niż o sprzęcie. Oto najbardziej oczywiste wnioski:
- OpenCL w programach użytkowych jest słabo wykorzystywany. Narzędzi jest niewiele, wspomagają się one GPU tylko w nielicznych operacjach, a wzrost wydajności jest wyraźnie zauważalny tylko w wybranych przypadkach. Jakby tego było mało, kompatybilność kuleje – choć OpenCL ma być standardem niezależnym od sprzętu, to wiele programów z jakichś powodów obsługuje tylko wybraną markę lub tylko niektóre modele kart graficznych.
- Nie każdy problem da się łatwo i z dobrym skutkiem zrównoleglić. Dobrym przykładem jest kodowanie wideo. Odkąd pojawiła się koncepcja GPGPU, była to jedna z dziedzin, w których spodziewano się największych zysków wydajności. Po wielu próbach przeniesienia całego procesu na GPU (pamiętacie Badaboom albo Avivo Video Converter?) na ogół ciągle używa się kodowania za pomocą CPU, ostatecznie stosuje wyspecjalizowane kodery (QuickSync). x264 z obsługą OpenCL wydaje się pierwszym udanym krokiem w tym kierunku, ale jak dowodzą problemy z rozdzieleniem pracy pomiędzy składniki APU, rozwiązanie wciąż jest niedojrzałe.
- Programowanie OpenCL jest trudne i niewygodne. Przypomnijmy wnioski z zeszłorocznego AMD Fusion Developer Summit: żeby osiągnąć obiecywany wzrost wydajności, często trzeba napisać kilkakrotnie więcej linii kodu, z czego większość to walka z modelem programowania, a nie usprawnianie algorytmu. Jeśli dodamy do tego stosunkowo powolne przesyłanie danych między RAM-em a pamięcią GPU oraz problemy z synchronizacją danych, to nie dziwi, że wielu programistów nawet nie próbuje na serio wykorzystać technik GPGPU.
Może kogoś nudzi ciągłe czytanie tego samego, ale my z przykrością musimy powtórzyć: oprogramowanie znajduje się w opłakanym stanie. Postęp techniczny w tej dziedzinie jest daleko w tyle za postępem w sprzęcie. Wydaje się, że nie ma drogi, która pozwoliłaby ominąć te problemy, trzeba je rozwiązać. Najlepszym pomysłem, o jakim do tej pory słyszeliśmy, jest znaczne uproszczenie modeli programowania. Takie techniki jak C++ AMP pozwalają w dodatkowej pracy (którą mało kto chce wykonać) zastąpić programistów kompilatorem i samymi urządzeniami wykonującymi kod. Dużym krokiem będzie też ujednolicenie przestrzeni adresowej CPU i GPU w ramach architektury HSA.
Choć nie ma na ten temat oficjalnych informacji, przecieki pozwalają sądzić, że nadchodząca nowa generacja konsol będzie zbudowana ze sprzętu zgodnego z HSA. To daje spore szanse na to, że nowa szkoła programowania wkrótce się upowszechni i wspomaganie GPU wreszcie zacznie działać bezproblemowo. Nie będzie trzeba sprawdzać listy obsługiwanych kart graficznych, włączać domyślnie wyłączonych opcji ukrytych w menu konfiguracji, mierzyć wydajności, aby sprawdzić, czy aby na pewno wykorzystanie GPU przyspiesza pracę, gapić się na komunikaty o błędach dotyczące zawieszających się programów...
Na razie zwykły użytkownik nie ma co się zbytnio przejmować OpenCL. Dobieranie sprzętu pod tym kątem jest bez sensu, bo wszystkie nowoczesne procesory i GPU o interesującej wydajności obsługują ten standard. Dobieranie oprogramowania też nie jest zbyt ciekawym zajęciem, bo wybór jest znikomy. Pozostaje śledzić rozwój techniki i czekać, aż to wszystko zacznie porządnie działać :)