Programowanie procesorów graficznych GPGPU 1
GPGPU Historia: lata 80 te popularyzacja systemów i programów z graficznym interfejsem specjalistyczne układy do przetwarzania grafiki 2D lata 90 te standaryzacja potoku przetwarzania grafiki 3D (OpenGL, DirectX) vertex shaders pixel shaders procesory graficzne 3D XXI wiek programowalne układy graficzne (programmable shaders) język Cg początek GPGPU 2
GPGPU historia 3
GPGPU historia 4
GPGPU historia 5
GPGPU Listopad 2006: architektura Tesla ujednolicona architektura, zamiast pixel shaders i vertex shaders standardowe skalarne procesory (nazywane obecnie rdzeniami CUDA CUDA cores ) procesor G80 karta graficzna NVIDIA GeForce 8800 model programowania CUDA (Compute Unified Device Architecture) środowisko programowania C for CUDA 6
TESLA architecture CUDA G80 2006 7
CUDA 8
GPGPU historia 9
GPGPU historia 10
GPGPU Programowanie ogólnego przeznaczenia na procesorach graficznych (GPGPU) nowe narzędzia zbliżone do narzędzi programowania równoległego na CPU rozszerzenia C + biblioteki CUDA, OpenCL dyrektywy OpenACC, OpenMP for accelerators model przetwarzania wyrażany w kategoriach zbliżonych do tradycyjnych rdzenie jako elementy przetwarzania hierarchia pamięci rejestry pamięć lokalna (nowość zarządzana z poziomu programu!) pamięć globalna (brak dostępu do pamięci dyskowej) 11
GPGPU Tworzenie programów GPGPU wykrycie współbieżności uwaga: masowa wielowątkowość opłacalność wykonywania na GPU tylko w przypadku wysokiego stopnia współbieżności (setki, tysiące wątków) odwzorowanie na architekturę uwaga: konieczność synchronizacji przy dostępie do pamięci GPU dobrze nadają się do obliczeń w stylu równoległości danych (te same obliczenia dla wielu egzemplarzy danych) duże możliwości konfiguracji obliczeń, a co za tym, idzie optymalizacji optymalizacja jawna (w ramach pojęć modelu programowania) optymalizacja niejawna (taka organizacja obliczeń, aby optymalnie wykorzystać elementy sprzętowe niewidoczne z poziomu modelu (języka, środowiska) programowania 12
GPGPU Modele programowania GPGPU Obydwa modele wykorzystują język C i biblioteki CUDA pierwszy naprawdę popularny model programowania GPGPU OpenCL wzorowany na CUDA, dla szerszej grupy urządzeń (GPU, CPU, procesory heterogeniczne, akceleratory) kod dla GPU w języku będącym rozszerzeniem standardu C99 założenie istnienia kompilatora, przetwarzającego kod dla GPU konieczne wsparcie ze strony systemu operacyjnego, który pośredniczy w wykonaniu programu (m.in. poprzez sterownik karty graficznej) Wykonanie programu realizowane jest w modelu SPMD/SIMD(SIMT) ten sam program wykonywany jest przez wiele wątków synchronizowanych sprzętowo 13
GPGPU Kod programu dla GPU tradycyjnie nazywa się kernelem Model SPMD jest wprowadzany klasycznie poprzez identyfikatory wątków wątek na podstawie swojego identyfikatora może: zlokalizować dane, na których dokonuje przetwarzania dane[ f(my_id) ] wybrać ścieżkę wykonania programu if(my_id ==...){...} określić iteracje pętli, które ma wykonać for( i=f1(my_id); i< f2(my_id); i += f3(my_id) ){... } w tym aspekcie programowanie GPU jest zbliżone do modeli Pthreads i MPI Środowiska programowania GPU pozwalają na wykorzystanie liczb wątków rzędu milionów 14
GPGPU Specyfika programowania GPU: dwa poziomy organizacji obliczeń wątki realizują obliczenia grupy wątków umożliwiają synchronizacją pracy wątków poziom grup wątków można pominąć (np. dla programów zawstydzająco równoległych (embarrassingly parallel) ) dwupoziomowa hierarchia pamięci dostępna programiście: zmienne lokalne dla grupy wątków o szybkim dostępie zmienne globalne o powolnym dostępie istnieje jeszcze poziom rejestrów jak zwykle ukryty przed programistą 15
16
17
18
Przebieg obliczeń Model wykonania: Komunikacja: synchroniczny data parallel SPMD (wykorzystanie identyfikatora wątku do podziału zadań) asynchroniczny task parallel poprzez argumenty procedur poprzez pamięć wspólną Synchronizacja bariery 19
Przebieg obliczeń Alokacja i inicjowanie pamięci na urządzeniu Przesłanie kernela do urządzenia w OpenCL można dokonywać w locie kompilacji kodu z dostarczanych źródeł Zlecenie wykonania obliczeń Kopiowanie danych z pamięci urządzenia Dodatkowo OpenCL umożliwia realizacje fazy wstępnej, w której pobiera się dane o środowisku wykonania i dostosowuje wykonywany program do konkretnego środowiska (urządzenia) 20
Przykład kod CPU iloczyn macierz wektor kod GPU (CUDA) iloczyn macierz wektor 21
Przykład Przykład dodawania wektorów (OpenCL) dekompozycja zadania analiza wydajności wydajność przetwarzania wydajność dostępu do pamięci informacje o liczbie wymiarów przestrzeni wątków, liczbie wątków (globalnej oraz w pojedynczej grupie), liczbie grup oraz o identyfikatorze wątku: lokalnym (w grupie), globalnym, a także o identyfikatorze grupy: get_work_dim() get_global_id(dim_id), get_local_id(dim_id) get_global_size(dim_id), get_local_size(dim_id) get_num_groups(dim_id), get_group_id(dim_id) 22
Projektowanie kerneli przykład Prosty przykład programu dodawania wektorów dekompozycja danych wariant 1 jeden wątek na jeden element wektora wykorzystanie możliwości tworzenia milionów wątków zawstydzająco równoległy algorytm brak komunikacji, synchronizacji kernel void vecadd_1_kernel( global const float *a, global const float *b, global float *result) { int gid = get_global_id(0); result[gid] = a[gid] + b[gid]; } 23
Projektowanie kerneli przykład Prosty przykład programu dodawania wektorów dekompozycja danych wariant 2 wykorzystanie wariantów podziału danych blokowanie jeden wątek operuje na bloku danych kernel void vecadd_2_blocks_kernel(..., const int size, const int size_per_thread) { int gid = get_global_id(0); int index_start = gid * size_per_thread; int index_end = (gid+1) * size_per_thread; for (int i=index_start; i < index_end && i < size; i++) { result[i] = a[i]+b[i]; } } 24
Projektowanie kerneli przykład Prosty przykład programu dodawania wektorów dekompozycja danych wariant 3 wykorzystanie wariantów podziału danych podział cykliczny kolejne wątki z grupy operują na kolejnych elementach wektorów strategia niewłaściwa dla CPU, najlepsza dla GPU kernel void vecadd_3_cyclic_kernel(..., const int size) { int index_start = get_global_id(0); int index_end = size; int stride = get_local_size(0) * get_num_groups(0); for (int i=index_start; i < index_end; i+=stride) { result[i] = a[i]+b[i]; } } 25
Projektowanie kerneli przykład Prosty przykład programu dodawania wektorów dekompozycja danych wariant 3 wykorzystanie wariantów podziału danych podział cykliczny wykorzystanie typów wektorowych nie zawsze optymalne (zależy od GPU NVIDIA rdzenie skalarne, AMD wektorowe) kernel void vecadd_4_cyclic_vect_kernel( global const float4 *a, global const float4 *b, global float4 *result, const int size) { int index_start = 4 * get_global_id(0); int index_end = size/4; int stride = 4 * get_local_size(0) * get_num_groups(0); for (int i=index_start; i < index_end; i+=stride) { result[i] = a[i]+b[i]; } } 26
Analiza wydajności Analiza wydajności może być przeprowadzana ma dwa standardowe sposoby: wydajność względna klasycznie oznacza to przyspieszenie i efektywność jako funkcje liczby procesorów/rdzeni dla pojedynczego GPU trudno przeprowadzać takie analizy analizy porównujące wydajność CPU i GPU stwarzają wiele problemów metodologicznych i powinny być używane tylko jako pewne wskazówki wydajność bezwzględna procent teoretycznej maksymalnej wydajności uzyskany dla danego wykonania programu wydajność może być ograniczana przez wydajność przetwarzania lub wydajność transferu danych z/do pamięci (dla obliczeń na GPU powinno się uwzględnić szybkości transferu dla wszystkich poziomów pamięci) 27
Przykład paramerów GPU Przykład karty graficznej (laptop Dell Vostro 3450): AMD Radeon HD 6630M 6 CU 480 PE 16384 rejestrów wektorowych (128 bitowych) / CU 32 kb pamięci wspólnej (32 banki) / CU 8 kb L1 / CU, 256 kb L2 / GPU 480 Gflops 25,6 GB/s DDR3, 51,2 GDDR5 ok. 250 GB/s pamięć wspólna maksymalny rozmiar grupy 256 (cztery wavefronts ) maksymalna liczba wavefronts 248 / GPU 28
GPGPU 29
Dalszy rozwój Platformy GPGPU innych producentów Rozwój architektur NVIDIA Fermi, Kepler AMD Radeon 79xx Środowiska programowania AMD (ATI Radeon) CtM, Stream, Brook IBM (PowerXCell) Cell SDK OpenCL OpenACC, C++AMP, Renderscript Wzrost wydajności 30
Problemy GPGPU GPU wymagają specyficznych algorytmów masowa wielowątkowość zgodny dostęp do obszarów pamięci wspólnej mało komunikacji, synchronizacji Aplikacje dostosowane do GPU zyskują wiele Jest wiele aplikacji, które zyskują mało lub nic 31