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

Następca OpenCL zapowiedziany!

Pamiętacie mój ostatni wpis o OpenCL? Pisałem w nim, że nie widzę OpenCL jako technologii przyszłości do programowania GPGPU. Przewidywałem także, że pojawi się nowa technologia, która ułatwi sposób tworzenia oprogramowania na GPU i wykorzysta przyszłe układy CPU i GPU. Przewidywania okazały się bardzo trafne i dzisiaj mogę wam powiedzieć jak ta technologia nazywa.

Tak więc po kolei:

I. Jak ta technologia się nazywa?

C++ AMP

II. Kto ją zapowiedział?

Herb Sutter w imieniu firmy Microsoft (w której pracuje) podczas konferencji organizowanej przez firmę AMD.

III. Co to jest C++ AMP?

Jest to otwarta specyfikacja rozszerzeń do języka C++ ver2011 (C++0x powinien zostać oficjalnie zatwierdzony w tym roku) zaproponowana przez Microsoft. Specyfikacja zawiera opis zestawu podzbiorów pełnego C++ i dodatkowej biblioteki z algorytmami i kontenerami. W obecnej chwili Microsoft mówi o jednym podzbiorze języka – podzbiorze pozbawionym m.in części operacji na wskaźnikach zgodnym z wymaganiami DirectCompute (elementu biblioteki DirectX 11). W przyszłej wersji Visual Studio Microsoft dostarczy dwie wersje kompilatora zgodnego z C++ AMP: domyślny pod CPU i w wersji restrict(direct3d) pod GPU. Kod pod CPU będzie wykonywał się natywnie, natomiast kod pod GPU będzie wykonywany poprzez bibliotekę DirectX 11. AMD zamierza stworzyć także swój własny kompilator pod C++ AMP (za pewne rozszerzy, któryś z open source’owych kompilatorów) i udostępni go pod systemy Windows, Linux i inne. Kompilator obsłuży kolejne generacje układów od AMD.

IV. Jak C++ AMP odnosi się do moich „5 punktów” z postu o OpenCL?

1. Ad: Możliwości zapisania programu w języku wysokiego poziomu bez sztucznego podziału: kod po stronie CPU, kod po stronie GPU

Kod tworzy się w języku C++ przy pomocą bibliotek, które znajdują się w specyfikacji C++ AMP. Poszczególne fragmenty kodu mogą zostać oznaczone jako restrict(nazwa_podzbioru). W zależności od poziomu restrykcji taki kod będzie się mógł uruchomić na różnych typach układów. Warto pamiętać, że kolejne generacje GPU będą coraz mniej restrykcyjne i w pewnym momencie mogą obsługiwać język C++ w pełni. Restrict nie mówi na jakim konkretnie układzie program ma działać a jaki zestaw funkcji taki układ musi posiadać. W tej chwili pełny zestaw zadziała tylko na CPU a zestaw direct3d na CPU i GPU (zarówno od AMD jak i Nvidii). Idea restrict jest znacznie szersza i po więcej informacji odsyłam do podlinkowanego wcześniej video z prezentacji C++ AMP. OpenCL zakładał, że GPU jest akceleratorem, który trzeba obsłużyć z poziomu kodu wykonywanego przez CPU (zainicjować, wysłać mu dane, uruchomić program, pobrać dane). C++ AMP zakłada, że posiadamy system z różnymi typami jednostek obliczeniowych i typami podsystemów pamięci (system heterogeniczny) a podział zadań pomiędzy tymi jednostkami, może być realizowany niejawne poprzez platformę C++ AMP. Jest to rozwiązanie bardziej ogólnie i sprawdzi się dużo lepiej przy kolejnych generacjach CPU i GPU.

2. Ad: Jak najniższego kosztu dostosowania obecnego oprogramowania do uruchomienia na GPU.

Programy pisze się w języku C++ więc jest to dużo ułatwienie, gdyż bardzo duża ilość oprogramowania została stworzona w tym języku. Niestety nie możemy oczekiwać, że koszt przeniesienia oprogramowania na C++ AMP będzie zerowy. Aby przenieść takie oprogramowanie czasem potrzebne będzie zastosowanie bardziej ogólnego mechanizmu do rozdzielania zadań czy użycie algorytmu, który lepiej skaluje się po rozdzieleniu na większą ilość wątków. Są to jednak rzeczy, które nie da się ominąć. Najważniejsze jest to, że nie mamy wielu sztucznych ograniczeń, które ma OpenCL.

3. Ad: 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).

O tym już pisałem w punkcie 1. C++ AMP ma bardziej przyszłościowy model programowania. Inną kwestią pozostaje to jak Nvidia i Intel odniosą się do tej technologii.

4. Ad: 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.

W przyszłości zarządzanie zadaniami i pamięcią na GPU będzie odbywać się podobnie jak teraz na CPU. C++ AMP świetnie wpisuje się w ten model.

5. Ad: 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.

Takie narzędzia ma posiadać następna wersja Visual Studio, łącznie z debuggerem kodu na GPU.

 

GPGPU ewoluuje i razem z nim podejście AMD-ATI. Za czasów Radeonów serii HD2xxx, HD3xxx, HD4xxx ATI udostępniało platformą opartą o kompilator Brook++. Ideą Brook++ było wykorzystanie GPU jako prostego procesora strumieniowego. To rozwiązanie przestało się sprawdzać razem z premierą Radeonów serii HD 5xxx (już przy Radeonach HD 4xxx słabo się sprawdzało), które posiadały wiele funkcji, z których nie można było skorzystać za pomocą Brook++. AMD porzuciło wtedy Brook++ i swoją uwagę skupiło na OpenCL. Tylko, że OpenCL też niedługo przestanie się sprawdzać. Prawdopodobnie już od Radeonów serii HD8xxx AMD będzie potrzebować czegoś więcej (C++ AMP) niż OpenCL.

Pozostaje pytanie co zrobi w tej sytuacji Nvidia. Jej CUDA było lepsze od Brook++, OpenCL zdobyło dość dużą popularność ale nie nadszarpnęło zbytnio pozycji platformy CUDA. Nvidia nawet olała implementacje OpenCL w wersji 1.1. Tylko, że teraz przeciwnik jest na prawdę duży. Co innego walczyć z firmą, która przeznacza znacznie mniejsze pieniądze na GPGPU (AMD kiedyś), a co innego walczyć z firmą, której heterogeniczne maszyny (kolejne generacje APU) są obecnie priorytetem nr 1. (AMD dziś) a pomaga jej firma Microsoft.

8 komentarzy to “Następca OpenCL zapowiedziany!”

  1. Dziękuję za dzielienie się swoją wiedzą. Miło poczytać kogoś kto wie co w trawie piszczy.

  2. Podpunkt 5 można już zaktualizować, bo intel wydał debugger dla OpenCL. Co więcej widać, że intensywnie wspiera OpenCL, przykładowo ich najanowszy pomysł: RiverTrail.

  3. Witam.
    Mam jedne konkretne pytanie dotyczace cpu czy gpu ? 🙂
    Komp bedzie mi sluzyl tylko i wylacznie do tradingu , broker swoja platforme udostepnia w javie ,system postawiony bedzie na Debianie ,monitor 32’/jeden . Co proponowlby pan wybrac ? Intela i7 czy Llano AMD ? Postawic mam na karte graficzna czy tez na procesor ? Priorytetem jest szybkosc i niezawodnosc ,cena nie gra zadnej roli .
    Dziekuje .

  4. @F1:
    To pytanie nie wiąże się mocno z tematem tego postu. Postaram się jednak szybko odpowiedzieć.

    Program napisany w javie można uruchomić tylko i wyłącznie na cpu. Jeśli program, który Pan używa nie korzysta z dodatkowych modułów napisanych w CUDA/OpenCL, to nie ma sensu inwestować w kartę graficzną. Zarówno Intel i7 (2xxx i 3xxx) jak i AMD Liano są dobrymi procesorami w swoich kategoriach cenowych. Nie wiem jednak co Pan zamierza dokładnie liczyć na tym komputerze więc trudno mi powiedzieć, który procesor będzie wystarczający.

  5. Panie Marcinie dziekuje ! ,przyznam ze nie spodziewalem sie tak szybko zobaczyc post .
    W Linuxie bede mial ustawionych ok. 20 obszarow roboczych ,a na nich okna z wykresami . Nie chce dodatkowych komplikacji z drugim monitorem . Do tego FF na wiadomosci .Na laptopie bede mial cala komunikacje – skype … , wiec interesuja mnie wylacznie charty od brokera . To wszystko . Doprawdy nie wiem czy platforma od brokera korzysta w wymienionych „modułów” . Jest oparta na javie – to tylko wiem .

  6. Witam,

    Małe pytanko, jak się ma udostępnienie c++APM’a na rożne platformy (np. linux), jesli kod GPU będzie wykonywany przez DirectX’a? Przecież to by oznaczało, że MS zamierza wydać także tą bibliotekę na inne platformy (co jest IMO bardzo mało prawdopodobne).

  7. @Rysiek.
    Musisz odróżnić specyfikację C++ AMP od jej implementacji. Specyfikacja jest otwarta to znaczy, że każdy może stworzyć implementacje zgodną z tą specyfikacją. Część związana z „Direct3D interoperability” jest opcjonalna tak więc nie ma przeszkód aby powstały implementacje, które z DirectX nie mają nic wspólnego. Microsoft nie planuje tworzyć implementacji pod Linuksa więc opieranie się na DirectX jest jak najbardziej rozsądne. Jeśli C++ AMP trafi na Linuksa to dlatego, że AMD i Nvidia stworzą odpowiednie implementacje w ramach swojego AMD APP i Nvidia CUDA (ewentualnie zrobi to ktoś za nich).

Leave a Reply