Programowanie procesorów graficznych do obliczeń ogólnego ...banas/SRR/SRR_W04_OpenCL_1.pdf ·...

Krzysztof Banaś Obliczenia równoległe 1

Programowanie procesorów graficznych do obliczeń ogólnego

przeznaczenia GPGPU


GPGPU motywacja


GPGPU – motywacja


Tendencje

➔ Mało dużych rdzeni rozbudowane potoki wykonanie poza

kolejnością wyrafinowane

przewidywanie rozgałęzień wiele jednostek

funkcjonalnych

➔ Dużo małych rdzeni prostsza budowa, krótsze

potoki wykonanie w kolejności proste przewidywanie

rozgałęzień mniej jednostek

funkcjonalnych


Architektura rdzeni – CPU versus GPU


GPGPU

➔ Historia: lata 80te – popularyzacja systemów i programów z graficznym

interfejsem• specjalistyczne układy do przetwarzania grafiki 2D

lata 90te – standaryzacja potoku przetwarzania grafiki 3D (OpenGL, DirectX)• vertex shaders• pixel shaders• procesory graficzne 3D

XXIwiek – programowalne układy graficzne (programmable shaders)• język Cg• początek GPGPU


GPGPU historia


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”


TESLA architecture – CUDA – G80 2006


CUDA


Programowanie akceleratorów – specyfikacja OpenCL


OpenCL

➔ OpenCL – Open Computing Language – język i środowisko programowania akceleratorów (procesorów wspierających standardowe CPU)

➔ Tzw. de facto standard, tworzony i wspierany przez grupę Khronos➔ Na bazie języka C (z uwzględnieniem C++, niezależnie od standardu

powstają wersje dla innych języków)➔ Z założenia przeznaczony dla rozmaitych akceleratorów (CPU, karty

Xeon Phi, GPU, procesory hybrydowe, takie jak IBM Cell) – różne architektury, różni producenci


OpenCL

➔ Specyfikacja definiuje cztery „modele”: Model platformy Model wykonania Model pamięci Model programowania

➔ Dwa pierwsze modele dotyczą organizacji pracy Współpraca systemu bazowego i akceleratora Tworzenie i uruchamianie programów na akceleratorze

➔ Dwa ostatnie ujmują specyfikę programowania akceleratorów

Abstrakcyjny model w ramach OpenCL Możliwość uwzględnienia specyficznych cech konkretnych

akceleratorów (GPU, Cell, Xeon Phi)


OpenCL – model platformy



➔ Model platformy – abstrakcyjny model sprzętu

Host – system podstawowy (program uruchomiony na systemie hosta zarządza programami na akceleratorach

Device – akcelerator (urządzenie?, diwajs?)

➔ Platforma jest jednocześnie pojedynczym wybranym środowiskiem wykonania programu na akceleratorze (na jednym komputerze można zainstalować i uruchamiać wiele platform)


OpenCL – podstawowe funkcje

cl_int clGetPlatformIDs( cl_uint num_entries, cl_platform_id *platforms, cl_uint *num_platforms )cl_int clGetPlatformInfo( cl_platform_id platform, cl_platform_info param_name, size_t param_value_size, void *param_value, size_t *param_value_size_ret)

➔ Parametry clGetPlatformInfo:

CL_PLATFORM_• PROFILE• VERSION• NAME• VENDOR• EXTENSION


OpenCL model platformy

➔ Akcelerator – device (urządzenie z interfejsem pamięci) Składa się z „compute units” procesory?, rdzenie? (posiadają

jednostki pobierania i dekodowania rozkazów) Każdy „compute unit” składa się z „processing elements”

rdzenie?, potoki? (służą do ostatecznej realizacji rozkazów)➔ Znaczenie pojęć „compute unit” (CU) i „processing

element” (PE) może być różne dla różnych typów akceleratorów – dlatego projektując oprogramowanie używać będziemy tylko określeń abstrakcyjnych – CU i PE

➔ W fazie optymalizacji dla konkretnej architektury należy uwzględnić rzeczywiste znaczenie CU i PE



➔ Standardowy procesor – CU = PE = rdzeń➔ AMD Radeon – CU = SIMD unit, PE = SIMD lane➔ NVIDIA GeForce – CU = SM, PE = CUDA core➔ IBM Cell – CU = PE = SPE➔ Intel Xeon Phi – CU = PE = rdzeń



cl_int clGetDeviceIDs ( cl_platform_id platform , cl_device_type device_type , cl_uint num_entries , cl_device_id *devices , cl_uint *num_devices )Podstawowe typy:CL_DEVICE_TYPE_CPUCL_DEVICE_TYPE_GPUCL_DEVICE_TYPE_ACCELERATOR+ CL_DEVICE_TYPE_ALL dla wszystkich typów



cl_int clGetDeviceInfo ( cl_device_id device , cl_device_info param_name , size_t param_value_size , void *param_value , size_t *param_value_size_ret ) Ponad 70 możliwych parametrów, m. in.:CL_DEVICE_GLOBAL_MEM_SIZE, CL_DEVICE_LOCAL_MEM_SIZE, CL_DEVICE_MAX_COMPUTE_UNITS, CL_DEVICE_MAX_CLOCK_FREQUENCYOraz wiele innych związanych np. z modelami pamięci i programowania


OpenCL – model wykonania

➔ Kontekst – zestaw danych wykorzystywanych do zarządzania wykonaniem programu na akceleratorach

➔ Pojedynczy kontekst istnieje w ramach konkretnej platformy i odnosi się do grupy akceleratorów (najczęściej tego samego typu)

➔ OpenCL wyróżnia 3 podstawowe typy akceleratorów:

CPU GPU ACCELERATOR



cl_context clCreateContext( const cl_context_properties *properties, cl_uint num_devices, const cl_device_id *devices, (void CL_CALLBACK *pfn_notify) ( const char *errinfo, const void *private_info, size_t cb, void *user_data), void *user_data, cl_int *errcode_ret)



cl_context clCreateContextFromType( const cl_context_properties *properties, cl_device_type device_type, const cl_device_id *devices, (void CL_CALLBACK *pfn_notify) ( const char *errinfo, const void *private_info, size_t cb, void *user_data), void *user_data, cl_int *errcode_ret)



cl_int clGetContextInfo ( cl_context context , cl_context_info param_name , size_t param_value_size , void *param_value , size_t *param_value_size_ret )Przykładowe parametry:CL_CONTEXT_NUM_DEVICES,CL_CONTEXT_DEVICES



➔ OpenCL dopuszcza możliwość realizacji poleceń przez akceleratory w sposób asynchroniczny i w kolejności niezależnej od kolejności zlecania

➔ Polecenia zlecane do wykonania na akceleratorze ustawiane są w kolejce – command queue

➔ Pojedyncza kolejka przypisana jest do pojedynczego akceleratora w ramach konkretnego kontekstu



cl_command_queue clCreateCommandQueue( cl_context context, cl_device_id device, cl_command_queue_properties properties, cl_int *errcode_ret)Własności:CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLECL_QUEUE_PROFILING_ENABLE



➔ Pojedyncze polecenie zlecane do wykonania akceleratorowi jest funkcją zwaną kernelem

➔ Kod składający się z jednego lub kilku kerneli nazywany jest programem

➔ Program jest tworzony z kodu źródłowego napisanego w języku OpenCL będącym ograniczona wersją C99

➔ Podstawowym sposobem tworzenia programu jest kompilacja w trakcie wykonania programu po stronie hosta

➔ Możliwe jest także wcześniejsze kompilowanie kodu i tworzenie programu z pliku binarnego



➔ Podstawowym założeniem OpenCL jest przenośność kodu

➔ Poprawny kod źródłowy OpenCL powinien zostać skompilowany i uruchomiony przez dowolne środowisko wykonania dla dowolnego akceleratora

➔ Do programu zawierającego wywołania kerneli OpenCL dołącza się (linkuje) tylko bibliotekę konkretnego środowiska wykonania, która powinna poprawnie utworzyć kernele i zarządzać ich wykonaniem

➔ Procedury biblioteki OpenCL mogą odwoływać się do kompilatorów i ich bibliotek dedykowanych do konkretnego akceleratora



cl_program clCreateProgramWithSource ( cl_context context, cl_uint count, const char **strings, const size_t *lengths, cl_int *errcode_ret)

cl_program clCreateProgramWithBinary ( cl_context context, cl_uint num_devices, const cl_device_id *device_list, const size_t *lengths, const unsigned char **binaries, cl_int *binary_status, cl_int *errcode_ret)



cl_int clBuildProgram ( cl_program program, cl_uint num_devices, const cl_device_id *device_list, const char *options, void (CL_CALLBACK *pfn_notify)( cl_program program, void *user_data), void *user_data)Standard OpenCL definiuje kilkanaście opcji kompilacji, można także przesyłać opcje dla konkretnych środowisk programowania



cl_int clCompileProgram ( cl_program program, cl_uint num_devices, const cl_device_id *device_list, const char *options, cl_uint num_input_headers, const cl_program *input_headers, const char **header_include_names, void (CL_CALLBACK *pfn_notify)( cl_program program, void *user_data), void *user_data)

cl_program clLinkProgram ( cl_context context, cl_uint num_devices, const cl_device_id *device_list, const char *options, cl_uint num_input_programs, const cl_program *input_programs, void (CL_CALLBACK *pfn_notify) ( cl_program program, void *user_data), void *user_data, cl_int *errcode_ret)



cl_int clGetProgramInfo ( cl_program program, cl_program_info param_name, size_t param_value_size, void *param_value, size_t *param_value_size_ret)cl_int clGetProgramBuildInfo ( cl_program program, cl_device_id device, cl_program_build_info param_name, size_t param_value_size, void *param_value, size_t *param_value_size_ret)

➔ Parametry clGetProgramInfo:

REFERENCE_COUNT CONTEXT NUM_DEVICES DEVICES BINARY_SIZES BINARIES NUM_KERNELS KERNEL_NAMES SOURCE

clGetProgramBuildInfo: BUILD_STATUS

BUILD_OPTIONS BUILD_LOG BINARY_TYPE



cl_kernel clCreateKernel ( cl_program program, const char *kernel_name, cl_int *errcode_ret)cl_int clSetKernelArg ( cl_kernel kernel, cl_uint arg_index, size_t arg_size, const void *arg_value)



➔ OpenCL umożliwia ograniczone zarządzanie obiektami w pamięci akceleratora przez program po stronie hosta

➔ Wykorzystuje się w tym celu pojęcie obiektu pamięci – memory object

➔ Istnieją dwa podstawowe rodzaje obiektów pamięci: Bufory – buffers, standardowe tablice Obrazy – images, obiekty o zoptymalizowanym,

charakterystycznym sposobie przechowywania, których specyfikacja umożliwia zastosowanie formatów używanych przez procesory graficzne do przechowywania rzeczywistych obrazów

➔ Bufory i obrazy mogę być tworzone, niszczone, ich zawartość kopiowana z pamięci hosta do pamięci akceleratora i z pamięci akceleratora do pamięci hosta


Tworzenie obiektów w pamięci GPU

cl_mem clCreateBuffer ( cl_context context, cl_mem_flags flags, size_t size, void *host_ptr, cl_int *errcode_ret);

➔ parametry typu cl_mem_flags: CL_MEM_READ_WRITE CL_MEM_WRITE_ONLY CL_MEM_READ_ONLY CL_MEM_USE_HOST_PTR CL_MEM_ALLOC_HOST_PTR CL_MEM_COPY_HOST_PTR



➔ Program uruchomiony po stronie hosta zleca zadania do wykonania przez akcelerator

➔ Pojedyncze zlecenie jest nazywane zdarzeniem – event➔ Dzięki zdarzeniom system wykonania OpenCL może

wprowadzić synchronizację realizowanych operacji Zależności między operacjami Oczekiwanie na zakończenie operacji

➔ Zdarzenia umożliwiają także pomiar czasu realizacji operacji i tworzenie profilu wykonania programu

➔ Zdarzeniami są np.: kopiowanie danych do i z pamięci akceleratora uruchomienie programu na akceleratorze



cl_int clEnqueueWriteBuffer ( cl_command_queue command_queue, cl_mem buffer, cl_bool blocking_write, size_t offset, size_t cb, const void *ptr, cl_uint num_events_in_wait_list, const cl_event *event_wait_list, cl_event *event)



➔ Wykonanie kernela jest zlecane środowisku wykonania OpenCL poprzez wywołanie odpowiedniej funkcji, z kernelem jako jednym z jej argumentów

➔ Z tego powodu przekazanie argumentów wywoływanemu kernelowi odbywa się w sposób różny od klasycznego

➔ Argumenty przypisuje się danemu kernelowi poprzez wywołanie specjalnej funkcji, która może jednocześnie spowodować przekazanie wartości argumentów do pamięci akceleratora



cl_int clSetKernelArg ( cl_kernel kernel, cl_uint arg_index, size_t arg_size, const void *arg_value)

➔ rozmiar danych najlepiej uzyskiwać operatorem sizeof np. sizeof(cl_mem) dla obiektów typu cl_mem tworzonych

przez clCreateBuffer



cl_int clEnqueueNDRangeKernel ( cl_command_queue command_queue, cl_kernel kernel, cl_uint work_dim, const size_t *global_work_offset, const size_t *global_work_size, const size_t *local_work_size, cl_uint num_events_in_wait_list, const cl_event *event_wait_list, cl_event *event)



➔ Po wykonaniu kernela należy zwolnić zasoby za pomocą funkcji:

clReleaseMemObject clReleaseKernel clReleaseProgram clReleaseCommandQueue clReleaseContext clReleaseEvent itp.


Sekwencja wykonania operacji OpenCL


OpenCL podsumowanie

Programowanie procesorów graficznych do obliczeń ogólnego ...banas/SRR/SRR_W04_OpenCL_1.pdf ·...

Documents

Transcript of Programowanie procesorów graficznych do obliczeń ogólnego ...banas/SRR/SRR_W04_OpenCL_1.pdf ·...