r   e   k   l   a   m   a
r   e   k   l   a   m   a

Heterogeniczne kolejkowanie: procesorowe równouprawnienie w wydaniu AMD

Strona główna AktualnościSPRZĘT

Heterogeniczna architektura obliczeniowa (HSA), którą od kilku miesięcy AMD opisuje jako przyszłość sprzętu IT, budzi coraz większe zainteresowanie zarówno producentów sprzętu, jak i oprogramowania. W rozwijającej ją Fundacji HSA znaleźć można m.in. konsorcjum ARM, Samsunga, LG, Texas Instruments, Qualcomm, Canonicala i Sony, a także ośrodki akademickie z USA, Wielkiej Brytanii i Chin. Do tej pory jednak nacisk kładło się na technologię hUMA, pozwalającą CPU i GPU na dostęp do tej samej pamięci. Jak jednak poradzić sobie z problemem przenoszenia zadań między procesorem głównym a procesorem graficznym? Odpowiedzią na to jest technologia hQ (heterogeneous queuing), stanowiąca ostatni krok na drodze do integracji procesorów w ramach HSA.

Do tej pory relacja między procesorem głównym a procesorem graficznym wyglądała następująco: aplikacja komunikowała się z CPU przez swoje kolejki zadań, zaś CPU poprzez usługi systemowe, interfejsy programowania i sterowniki sprzętu tworzył kolejkę zadań przekazywanych do GPU. Uniemożliwiało to w praktyce bezpośredni dostęp aplikacji do GPU – nie tylko nie mogła ona stworzyć bezpośrednio kolejki zadań dla GPU, ale też komunikacja przez CPU była obciążona wieloma warstwami abstrakcji (ten problem ma rozwiązać z kolei Mantle API).

hQ zmienia tę sytuację całkowicie – komunikacja między CPU i GPU staje się dwukierunkowa. Nie tylko CPU może tworzyć kolejki zadań dla GPU, ale też GPU może tworzyć kolejki zadań dla CPU. Co więcej, aplikacja zyskuje możliwość bezpośredniego kierowania zadań do GPU, z pominięciem abstrakcji systemu operacyjnego.

Idea wydaje się prosta, ale jej realizacja, z tego co można się było od AMD dowiedzieć, okazała się bardzo skomplikowana. Pozbycie się narzutu kolejnych warstw systemu operacyjnego okazało się możliwe poprzez wprowadzenie standardowego formatu pakietów danych dla CPU i GPU. Kolejki zadań dla CPU i GPU powstają z takich właśnie 64-bajtowych pakietów, umieszczanych w określonych obszarach pamięci. Przenoszą one informacje o typie pakietu, grupie roboczej, alokacji pamięci, wskaźniku do wykonywalnego obiektu w pamięci i argumentach dla jądra. Aplikacja może pakiety takie umieszczać równie dobrze w kolejkach CPU jak i GPU, bez ograniczeń co do ich długości. Najnowsze wersje układów APU od AMD mają obsłużyć do 50 takich kolejek. A jeśli 50 kolejek gwarantowanych przez sprzęt nie wystarczy, to możliwe będzie uruchomienie dodatkowej warstwy software'owej, pozwalającej na zarządzanie w praktyce nieograniczoną liczbą kolejek.

Wszystkie te operacje zachodzić mają w warstwie użytkownika, praktycznie bez odwołań do jądra systemu. Pozwala to na bezpieczne i oszczędne uruchamianie aplikacji, bez narzutu i przyznawania nadmiernych uprawnień. W zasadzie jest to realizacja obietnic, jakie towarzyszyły wprowadzeniu pierwszych APU – procesor główny może realizować zadania szeregowo, by w połowie pracy przekazać część zadań związaną z przetwarzaniem równoległym do procesora graficznego, z minimalnymi, niedostrzegalnymi dla użytkownika opóźnieniami. Ten zaś, po ukończeniu pracy może przekazać wyniki z powrotem do kolejki CPU.

Taka architektura raczej jednak nie będzie się spisywała poza APU, dla użytkowników dyskretnych kart graficznych. Narzut związany z komunikacją po PCI Express byłby tak duży, że szybciej byłoby robić wszystko na CPU, niż bawić się w czasochłonne przerzucanie zadań między CPU a GPU.

Pozostaje jeszcze kwestia tego, w jaki sposób hQ rozdziela zadania między CPU i GPU? Z tego co wynika z informacji od AMD, problem ten rozwiązano najprościej jak tylko można. Wszystko robione jest ręcznie – od programisty zależy, gdzie dane zadanie zostanie wykonane. W zasadzie sytuacja przypomina to, jak wygląda programowanie równoległe dzisiaj: narzędzia do profilowania będą sugerowały po prostu te obszary kodu, które warto uruchamiać na GPU.

Prawdopodobnie pierwszym językiem programowania, który będzie wykorzystywał hQ i inne technologie HSA będzie Java. O tym może świadczyć zaproszenie Oracle'a na zbliżającą się konferencję APU13. Na pewno na tym jednak AMD nie zaprzestanie – obiecywana jest cała paleta narzędzi dla deweloperów, która pozwolić ma na pełne wykorzystanie możliwości heterogenicznej architektury.

r   e   k   l   a   m   a
© dobreprogramy

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.