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

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

„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.

3 komentarze to “OpenCL – czy to na pewno technologia przyszłości?”

  1. „# Możliwości zapisania programu w języku wysokiego poziomu bez sztucznego podziału: kod po stronie CPU, kod po stronie GPU
    # Jak najniższego kosztu dostosowania obecnego oprogramowania do uruchomienia na GPU.”

    Ale to samo w sobie jest absurdalne. Jak można oczekiwać że synchroniczne albo prawie-synchroniczne (czyli MT z mnóstwem blokad/muteksów itp) będzie dobrze działało na platformie wykonującej naraz kilka tysięcy wątków? Sama różnica w architekturze powoduje to że potrzebna jest inna filozofia kodu (podobnie jak np. SPU na platformie CELL).

    Notabene z mojego punktu widzenia (gamedev) największą przeszkodą jest to że GPGPU jest związane z kartą graficzną. Tymczasem w znakomitej większości gier GPU ma wystarczająco dużo do roboty i zrzucanie na niego dodatkowych obliczeń nie daje spodziewanych korzyści. Czekam na trend podwójnych GPU 🙂 (ale nie SLI, tylko osobne karty dla OpenGL i OpenCL)

  2. @Tomasz Dąbrowski:
    W całości zgadzam się, że nie można oczekiwać że kod z mnóstwem blokad/ muteksów będzie działał dobrze na platformie wykonującej kilka tysięcy wątków. Powiem więcej. Taki kod nie będzie działał dobrze na platformie wykonującej 10 wątków. A przecież najszybsze Core i7 mają ich więcej. Po prostu ten problem to także problem CPU a nie tylko GPU.

    Sposób programowania CPU się zmienia, odpowiednie wykorzystanie 10 wątków to już duże wyzwanie. Musimy rozwijać takie rozwiązania jak Intel Threading Building Blocks, ConcRT z Visual Studio 2010 (zwłaszcza w połączeniu z UMS dostępnym w Windows 7), czy rozwiązaniami, które .NET wprowadził w wersji 4.0

    Weź też pod uwagę, że liczba sprzętowo obsługiwanych wątków na CPU stale rośnie podczas gdy na GPU ostatnio się zmniejszyła (GT200 -> GF100). Z tego wynika że różnica pomiędzy CPU a GPU się zmniejsza.

    Cell jest rzeczywiście inny, tylko że z rozwiązań zastosowanych w Cellu świat się obecnie wycofuje. Po prostu świat oprogramowania nie jest gotowy na takie zmiany w tej chwili. One pewnie wrócą ale za dobre kilka lat (2015-2020r?). Nie będziemy mieć w międzyczasie układów heterogenicznych, a komunikacja pomiędzy rdzeniami będzie odbywać się przede wszystkim za pomocą wielostopniowego ale zsynchronizowanego cache. Chodzą plotki, że PS4 będzie miało właśnie tego typu procesor tylko po prostu z dużą liczbą rdzeni. Projekt udziwnionego Larrabee upadł (na szczęście). Za to dostajemy układy z serii Knights, które już żadnych udziwnień nie mają. Przyszłe GPU też wpasowują się w ten trend. Po prostu rozwijajmy technologie o których pisałem wcześniej w tym komentarzu jednocześnie tworząc nowe rozwiązania, które poradzą sobie z bardziej udziwnionymi architekturami i dopiero niech wtedy wchodzą te „udziwnione” architektury.

    Oczywiście piszę tutaj bardzo ogólnie o GPGPU. Jeśli zawęzimy temat do gamedev to w pełni się z Tobą zgadzam. OpenCL jako kompan OpenGL jest dobrym rozwiązaniem. Rzeczywiście potrzebujemy silnika fizycznego, który będzie działał dobrze na kartach AMD, NVidii i przede wszystkim o ile to możliwe na CPU. Jest to zadanie bardzo trudne więc będziemy musieli na nie chwilę poczekać. Gdy się to uda, producenci gier będą mogli wprowadzić efekty fizyczne jako nieoderwalny element gry, bez którego gra traci sens. Wtedy zdobędziemy podziw gracz, a wtedy oni chętnie kupią nawet quadGPU 😉

  3. […] mój ostatni wpis o OpenCL? Pisałem w nim, że nie widzę OpenCL jako technologii przyszłości do programowania GPGPU. […]

Leave a Reply