Heterogeniczne kolejkowanie: procesorowe równouprawnienie w wydaniu AMD

Heterogeniczna architektura obliczeniowa (HSA), którą od kilkumiesięcy AMD opisuje jako przyszłość sprzętu IT, budzi coraz większezainteresowanie zarówno producentów sprzętu, jak i oprogramowania. Wrozwijającej ją Fundacji HSA znaleźć można m.in. konsorcjum ARM,Samsunga, LG, Texas Instruments, Qualcomm, Canonicala i Sony, a takżeośrodki akademickie z USA, Wielkiej Brytanii i Chin. Do tej poryjednak nacisk kładło się na technologięhUMA, pozwalającą CPU i GPU na dostęp do tej samej pamięci. Jakjednak poradzić sobie z problemem przenoszenia zadań międzyprocesorem głównym a procesorem graficznym? Odpowiedzią na to jesttechnologia hQ (heterogeneous queuing), stanowiąca ostatni krok nadrodze do integracji procesorów w ramach HSA.Do tej pory relacja między procesorem głównym a procesoremgraficznym wyglądała następująco: aplikacja komunikowała się z CPUprzez 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średnidostęp aplikacji do GPU – nie tylko nie mogła ona stworzyćbezpośrednio kolejki zadań dla GPU, ale też komunikacja przez CPUbyła obciążona wieloma warstwami abstrakcji (ten problem ma rozwiązaćz kolei Mantle API).[img=hsa]hQ zmienia tę sytuację całkowicie – komunikacja między CPU iGPU 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, zpominięciem abstrakcji systemu operacyjnego.[img=cpu-gpu-wo-hq][join][img=cpu-gpu-w-hq]Idea wydaje się prosta, ale jej realizacja, z tego co można siębyło od AMD dowiedzieć, okazała się bardzo skomplikowana. Pozbyciesię narzutu kolejnych warstw systemu operacyjnego okazało się możliwepoprzez wprowadzenie standardowego formatu pakietów danych dla CPU iGPU. Kolejki zadań dla CPU i GPU powstają z takich właśnie64-bajtowych pakietów, umieszczanych w określonych obszarach pamięci.Przenoszą one informacje o typie pakietu, grupie roboczej, alokacjipamięci, wskaźniku do wykonywalnego obiektu w pamięci i argumentachdla jądra. Aplikacja może pakiety takie umieszczać równie dobrze wkolejkach CPU jak i GPU, bez ograniczeń co do ich długości. Najnowszewersje układów APU od AMD mają obsłużyć do 50 takich kolejek. A jeśli50 kolejek gwarantowanych przez sprzęt nie wystarczy, to możliwebędzie uruchomienie dodatkowej warstwy software'owej, pozwalającej nazarzą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 ioszczędne uruchamianie aplikacji, bez narzutu i przyznawanianadmiernych uprawnień. W zasadzie jest to realizacja obietnic, jakietowarzyszyły wprowadzeniu pierwszych APU – procesor główny możerealizować zadania szeregowo, by w połowie pracy przekazać częśćzadań związaną z przetwarzaniem równoległym do procesoragraficznego, z minimalnymi, niedostrzegalnymi dla użytkownikaopóźnieniami. Ten zaś, po ukończeniu pracy może przekazać wyniki zpowrotem 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 zkomunikacją 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 zadaniamiędzy CPU i GPU? Z tego co wynika z informacji od AMD, problem tenrozwią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 programowanierównoległe dzisiaj: narzędzia do profilowania będą sugerowały poprostu te obszary kodu, które warto uruchamiać na GPU. Prawdopodobnie pierwszym językiem programowania, który będziewykorzystywał 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 jestcała paleta narzędzi dla deweloperów, która pozwolić ma na pełnewykorzystanie możliwości heterogenicznej architektury.