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

Następca OpenCL zapowiedziany!

Czerwiec 19th, 2011 Marcin Borowiec

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.