Programowanie współbieżne, Języki programowania, Aplikacje, Gry

OpenCL – czy to na pewno technologia przyszłości?

Wrzesień 25th, 2010 Marcin Borowiec

„OpenCL będzie wiodącą technologią na rynku GPGPU”, „OpenCL jest standardem przyszłości”, „NVidia powinna skupić się na obsłudze OpenCL, a nie nadal promować swoje rozwiązania”. Coraz częściej widzę i słyszę takie stwierdzenia. Według mnie są one stanowczo przesadzone  (może oprócz tego pierwszego ).

Teraz OpenCL jest na fali bo:

  • Właściciele Radeonów mają poczucie, że ich karty są czymś więcej niż tylko kalkulatorem do trójkątów.
  • Programista teoretycznie jest w stanie napisać program, który zadziała na kartach NVidii i AMD-ATI.
  • OpenCL dobrze wpasowuje się w obecną sytuacje na rynku pod względem technologicznym (budowa GPU, sposób obsługi karty graficznej w systemie operacyjnym)
  • OpenCL lansowany jest na technologię dzięki, której programista napisze program raz a później uruchomi go na CPU, GPU, WPU (washer processing unit), no dobrze, z tym ostatnim trochę przesadziłem.
  • OpenCL jest pod Windows, Linux, Mac OS

Natomiast to co ja (i pewnie wielu innych programistów) oczekuje od technologii przyszłości to:

  1. Możliwości zapisania programu w języku wysokiego poziomu bez sztucznego podziału: kod po stronie CPU, kod po stronie GPU
  2. Jak najniższego kosztu dostosowania obecnego oprogramowania do uruchomienia na GPU.
  3. Wykorzystania potencjału przyszłych układów: Kolejne wersje układów od NVidii i AMD, rozwiązania Intela z rodziny Knights (Knights Ferry i Knights Corner).
  4. Wykorzystania potencjału jaki przyniosą nowe modele sterowników, chodzi tu m.in o WDDM 2.1 (Windows Display Driver Mode), który pojawi się prawdopodobnie w Windows 8.
  5. Narzędzi: debuggery, profilery itp które obsługiwać będzie się podobnie do tych, które obecnie używane są dla programów pisanych pod CPU.

Oczywiście OpenCL pozwoli uruchamiać programy na przyszłych urządzeniach ale niekoniecznie będzie się takie programy opłacało pisać w OpenCL. To co jest potrzebne to platforma, która pozwoli tanim kosztem pisać programy pod GPU. Co ciekawe to patrząc pod tym kątem to technologia CUDA wypada dużo lepiej od OpenCL. Odnosząc się do wcześniejszych punktów:

  1. OpenCL zakłada, że GPU czy inne APU są po prostu akceleratorami, które sterowane są przez hosta. Hostem jest tutaj typowy CPU. Piszemy więc kod, który inicjalizuje urządzenie (akcelerator), przesyła do niego dane, kompiluje i wczytuje program do akceleratora, uruchamia go i pobiera wyniki. API do sterowania akceleratorem udostępnione jest jako biblioteka języka C, można więc ją łatwo wykorzystać w kodzie C/C++ lub za pomocą bindingów w innych bardziej wysokopoziomowych platformach. Gorzej jest z kodem, który ma zostać uruchomiony na akceleratorze. Piszemy go w dość prymitywnym języku opartym na języku C dostosowanym do potrzeb OpenCL. Dane wymieniane pomiędzy hostem a akceleratorem traktowane są jako dane binarne i każda strona powinna sama je odpowiednio zinterpretować. W porównaniu do pisania programów wyłącznie dla CPU jest to dużo bardziej kłopotliwe. W takim wypadku OpenCL będzie miał zastosowanie tylko tam gdzie: oczekiwany wzrost wydajności jest bardzo duży, ten wzrost przekłada się także na dużo większy zarobek, który pokryje różnice w trudności programowania pomiędzy CPU a CPU i GPU.
  2. Jeszcze większe różnice w kosztach istnieją gdy na OpenCL chcemy przerobić istniejące oprogramowanie. Porównujemy tutaj utrzymanie kodu tylko dla CPU do przepisania części kodu na GPU (tego, które da się przenieść i da jakiś zysk). A co by było gdyby istniała technologia, która pozwoli na dużo tańsze dostosowanie takiego kodu do GPU? Obecnie problemem jest samo GPU jak i sposób zarządzania GPU w systemie operacyjnym. Ale co z kolejnymi wersjami GPU i systemów operacyjnych. Czy założenia OpenCLa pozwolą mu się tak szybko rozwijać? Tutaj jestem dość sceptycznie nastawiony ale może Khronos Group ma jakiś genialny pomysł, którym się na razie nie chwali.
  3. To czego możemy się spodziewać po przyszłych GPU możemy się domyślać po ostatnich zapowiedziach NVidii dotyczące następców układu Fermi jak i modelu sterowników, który trafi do nowszych wersji systemu Windows. Dla przypomnienia w Windows Vista mamy WDDM 1.0 a w Windows 7 mamy WDDM 1.1. To co nas interesuje to opublikowane już jakiś czas temu plany dotyczące WDDM 2.0 i WDDM 2.1: Pierwotnie zakładano że WDDM 2.x pojawi się dużo wcześniej (w Windows 7?) ale realia zmusimy Microsoft do zmiany planów. Co nie zmienia faktu, że kiedyś (w Windows 8?) WDDM 2.0 i 2.1 się pojawi i jest duża szansa że będzie własnie taki jaki planowano że będzie. Ostatnie informacje o układach NVidia Kepler i Maxwell to potwierdzają. Mamy więc dwa podejścia: pierwsze to podejście OpenCL, piszmy jeden program ale w sposób prymitywny i uruchamiajmy go na CPU, obecnych i przyszłych GPU a także innych prostych akceleratorach i drugie: dostosujmy GPU do tego żeby programowało się i korzystało z niego niemal identycznie jak z CPU. Ja wole to drugie podejście. Microsoft i NVidia też 😉
  4. Jak wyżej 🙂
  5. Istnienie debuggerów i profilerów  nie jest aż tak bardzo powiązane z tym czy program pisany jest w OpenCL czy CUDA więc pominę ten punkt.

Z drugiej strony mamy podejście NVidii w postaci CUDA.

  1. Na początku warto powiedzieć że CUDA to szersze pojęcie. Mamy tutaj zestaw narzędzi nisko i wysokopoziomowych. Niskopoziomowe czyli Driver API to podejście podobne do OpenCL w tym względzie że traktujemy GPU jako akcelerator, którego trzeba zainicjować, skonfigurować, wysłać dane i program itp itd. Program, który tutaj wysyłamy do API akceleratora jest asemblerem. Driver API skierowane jest dla maniaków wydajności jak i programistów platform opartych o CUDA. Dla programistów typowych aplikacji pod CUDA mamy przede wszystkim CUDA C, które na pierwszy rzut oka wydawać by się mogło jest podobne do C z OpenCL ale tak nie jest. CUDA C stara się jak najbardziej zakryć proces konfiguracji i inicjalizacji akceleratora tak samo jak podział pomiędzy kodem CPU i GPU. Oczywiście podział istnieje ale jest i będzie on stopniowo zamazywany przez kolejne wersję oprogramowania CUDA jak i układów GPU.
  2. Jak widać rozwój CUDA ma stopniowo zmniejszać koszt pisania programów pod tą platformę jak i koszt dostowania obecnego kodu do tej platformy. Dla przykładu pierwsze wersje CUDA oferowały wyłącznie wsparcie dla konstrukcji znanych z języka C (choć operacja na wskaźnikach są dość mocno limitowane na urządzenia z CUDA Capability 1.x) to obecne wersje stopniowo wprowadzają obsługę języka C++.
  3. To co możemy spodziewać się po przyszłych GPU napisałem przy okazji pisania przy OpenCL. Tutaj wspomnę, że CUDA będzie się naturalnie rozszerzać i dostosowywać do przyszłej sytuacji
  4. Jak wyżej 🙂
  5. Pod platformę CUDA mamy środowisko NVidia Parallel Insight. Obecnie ma jeszcze dużo ograniczeń ale jasno pokazuje w jakim kierunku zmierza NVidia. Za pewne długo jeszcze poczekamy zanim AMD zaoferuje coś podobnego.

Popatrzmy także na podejście Intela. Firma ta jakoś specjalnie nie jest zainteresowana OpenCL. Obecnie oferuje procesory x86 z rodziny Core, układy GPU (zintegrowane we wcześniejszych platformach z chipsetem a obecnie z procesorem) a w przyszłości układy z rodziny Knights zgodne z x86. Procesory Core i układy Knights można będzie programować w języku C++ przy pomocą narzędzi/bibliotek takich jak Threading Building Blocks. Jak się do tego odnosi OpenCL? Nie ma żadnych przeszkód, żeby wykorzystać OpenCL do programowania procesorów z rodziny Core czy Knights tylko po co to robić skoro można to robić zwyczajnie w C++? GMA z kolei jest mało wydajne i wystarczy, że w dość dobrym stopniu zaoferuje akceleracje DirectX i odtwarzania filmów i to wszystko co potrzeba.

Podsumowując: Obecnie wykorzystanie GPU jest dość drogie i czasochłonne, dlatego przez najbliższe 2-3 lata GPGPU nie stanie się tak bardzo popularne jak wiele osób mogło by oczekiwać. Z kolei za kilka lat sytuacja będzie wyglądać dużo lepiej ale nie dlatego że OpenCL spopularyzuje GPGPU tylko dlatego, że GPGPU ewoluuje i będą dużo lepsze technologie do programowania GPGPU (chociaż to pewnie już nie będzie się nazywać GPGPU), lepsze niż obecny OpenCL.

Zostawiam wam więc temat do przemyśleń a dla siebie spisany tekst, do którego będę mógł wrócić za kilka lat i sprawdzić czy i jak bardzo się pomyliłem.