OpenCL 2.0

OpenCL 2.0 to znacząca aktualizacja standardu, wprowadzająca m.in. współdzieloną pamięć wirtualną między CPU a GPU.

Zakres zmian wprowadzonych przez OpenCL 2.0

OpenCL 2.0 jest wersją standardu firmy Khronos Group przeznaczoną do programowania heterogenicznych systemów obliczeniowych. Taki system może łączyć procesor ogólnego przeznaczenia CPU, procesor graficzny GPU, układ DSP albo inne urządzenie obliczeniowe. Program OpenCL składa się z kodu wykonywanego po stronie hosta oraz funkcji zwanych kernelami, uruchamianych na wybranym urządzeniu. Wersja 2.0 rozszerzyła model programowania w taki sposób, aby większa część pracy mogła być organizowana bezpośrednio przez urządzenie obliczeniowe, a nie wyłącznie przez kod hosta.

Najbardziej charakterystyczną zmianą jest współdzielona pamięć wirtualna, określana jako Shared Virtual Memory, czyli SVM. Pozwala ona na udostępnianie określonych obszarów pamięci zarówno kodowi hosta, jak i kernelom. W zależności od poziomu obsługi urządzenie może korzystać z pamięci współdzielonej w sposób podstawowy albo z bardziej zaawansowanych mechanizmów, obejmujących również wskaźniki i struktury danych. Sam fakt zgodności z OpenCL 2.0 nie oznacza jednak, że każdy sterownik udostępnia wszystkie poziomy SVM.

Shared Virtual Memory i wskaźniki w kernelach

W starszym modelu OpenCL dane były zwykle przekazywane pomiędzy hostem a urządzeniem za pomocą jawnych operacji kopiowania, takich jak transfer do pamięci urządzenia i transfer z powrotem do pamięci hosta. OpenCL 2.0 wprowadza możliwość użycia buforów SVM, dzięki czemu host może przydzielić obszar pamięci przeznaczony do współpracy z urządzeniem. W prostszym wariancie program nadal musi kontrolować synchronizację i zapewnić, aby CPU oraz urządzenie nie modyfikowały danych jednocześnie w sposób prowadzący do wyścigu.

Ważną funkcją jest fine-grain SVM, czyli drobnoziarnista współdzielona pamięć wirtualna. W tym modelu urządzenie może obserwować zmiany wykonywane przez hosta bez konieczności przeprowadzania klasycznego kopiowania całego bufora, o ile dane urządzenia i sterownik obsługują wymagany poziom funkcji. OpenCL 2.0 definiuje również możliwość używania wskaźników w pamięci współdzielonej, co ułatwia przekazywanie złożonych struktur, list lub grafów. W praktyce trzeba sprawdzić właściwości konkretnego urządzenia, ponieważ obsługa SVM jest raportowana osobno i może ograniczać dostępne zastosowania.

Do synchronizacji operacji wykonywanych przez różne jednostki obliczeniowe mogą służyć atomowe operacje pamięci oraz mechanizmy synchronizacji przewidziane przez model pamięci OpenCL. Atomowość nie rozwiązuje jednak każdego problemu z kolejnością operacji. Program musi określić, kiedy dane są gotowe do odczytu, jaki zakres pamięci jest współdzielony oraz jakie zależności występują między kernelami. Błędna synchronizacja może powodować wyniki zależne od obciążenia, sterownika lub kolejności wykonania.

Kolejki, rury i uruchamianie pracy przez urządzenie

OpenCL 2.0 wprowadza device-side enqueue, czyli możliwość dodawania poleceń do kolejki przez kernel wykonywany na urządzeniu. W poprzednim modelu to host zazwyczaj przygotowywał kolejne uruchomienia i umieszczał je w kolejce poleceń. Device-side enqueue pozwala budować bardziej dynamiczne algorytmy, w których urządzenie samo uruchamia kolejne etapy obliczeń po spełnieniu określonych warunków. Przydatne jest to między innymi przy przetwarzaniu danych o nieregularnej strukturze, gdy liczba kolejnych zadań nie jest znana przed rozpoczęciem obliczeń.

Do obsługi takiego mechanizmu OpenCL 2.0 definiuje kolejki poleceń dostępne z poziomu urządzenia. Ich użycie wymaga odpowiednich zasobów sprzętowych i wsparcia sterownika, a ponadto może zwiększać złożoność synchronizacji. Programista musi kontrolować zależności między zdarzeniami, ograniczenia liczby kolejek oraz sposób, w jaki pamięć jest udostępniana kolejnym kernelom.

Drugim rozpoznawalnym elementem są pipes, czyli potoki służące do przekazywania danych pomiędzy kernelami. Potok ma charakter kolejki elementów i może być używany do komunikacji producenta z konsumentem. OpenCL C 2.0 udostępnia funkcje pozwalające między innymi na odczyt i zapis elementów potoku. Rozwiązanie to nie jest zwykłym buforem przechowującym dowolne dane; obowiązują określone reguły typów, dostępu i synchronizacji. Również w tym przypadku dostępność funkcji zależy od faktycznych możliwości urządzenia zgłoszonych przez platformę OpenCL.

Weryfikacja zgodności OpenCL 2.0 na komputerze

Przy ocenie działania OpenCL 2.0 nie wystarczy sprawdzić nazwy karty graficznej. O zgodności decyduje przede wszystkim połączenie urządzenia, sterownika oraz platformy OpenCL zainstalowanej w systemie. Program może odczytać między innymi wersję platformy, listę urządzeń, obsługiwane rozszerzenia, rozmiar pamięci, dostępne typy pamięci SVM oraz możliwości kolejek urządzenia. Brak konkretnej funkcji może wynikać ze sterownika, mimo że sam układ obliczeniowy ma odpowiednie możliwości sprzętowe.

Praktyczna diagnostyka powinna obejmować sprawdzenie, czy aplikacja wybrała właściwą platformę i urządzenie, czy kernel został skompilowany dla oczekiwanej wersji języka oraz czy używane funkcje są faktycznie raportowane jako dostępne. Należy też rozróżnić błąd kompilacji kernela od błędu uruchomienia. Kernel korzystający z funkcji OpenCL 2.0 może nie skompilować się na urządzeniu udostępniającym wyłącznie starszą wersję języka albo może zostać odrzucony podczas tworzenia kolejki, bufora SVM lub potoku.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów stacjonarnych PC oraz ich podzespołów, dlatego przy problemach z działaniem aplikacji wykorzystujących OpenCL można rozpocząć od sprawdzenia sprzętu, sterownika graficznego i konfiguracji systemu. Sama aktualizacja sterownika nie gwarantuje jednak pełnej zgodności z OpenCL 2.0. Wynik zależy od konkretnego urządzenia i implementacji dostarczonej przez producenta.