AMD A10 7850K

HSA i hUMA

Suštinski gledano, HSA odnosno hUMA – „heterogenous Uniform Memory Access“ je ideja koja je već viđena pre više od 20 godina. Ako se podsetimo stare dobre Amige i organizacije memorije, videćemo da ima mnogo sličnosti. Custom čipovi za grafiku i zvuk koristili su deljen adresni prostor sa CPU-om i taj deo memorije zvao se „chip“ RAM, kojem su pristupali i CPU i „custom“ čipovi. Ono što je zanimljivo u celoj priči je Amigin koprocesor, „copper“ koji je bio programabilan i koristio je 68K memorijske adrese za pristup memoriji. Posle više od 20 godina, istorija se ponavlja, ali je sve dodatno zakomplikovano brojnim softverskim „layer-ima“, masivnom paralelizacijom i daleko većom programabilnošću nego što je to slučaj sa Amiginim Copper-om.

Originalan naziv potiče od UMA – Uniform Memory Architecture, koji predstavlja način na koji sistem vidi i pristupa memoriji. Do sada smo se susretali sa nazivima poput NUMA – Non-Uniform Memory Architecture na serverskim sistemima, gde svaki CPU čvor poseduje svoju memoriju, a koherencija se odvija putem koherentnih linkova, u slučaju Opterona putem Hypertransport linkova. Koherencija je neugodan zahtev iz prostog razloga jer znatno komplikuje programski model samog hardvera, koji mora da vrši na najoptimalniji mogući način sinhronizaciju, kopiranje i translaciju memorijskih adresa između „nodova“. Konkretno kod APU-a do sada je korišćen NUMA pristup, jer je deo memorije odvajan za GPU, a naknadno je vršena koherencija podataka između CPU-a i GPU-a.

Sada dolazimo do onoga što smo već spomenuli malopre u tekstu. APU baziran na HSA arhitekturi koristi x86-64 pokazivače za pristup celoj memoriji. Dakle, CPU može da pristupi bilo kojem delu CPU i GPU memorije i obrnuto pri tom koristeći zajednički MMU – memory management unit, koji je deo memorijskog kontrolera u samom APU. To ne znači da GPU i dalje ne koristi lokalnu memoriju ili framebuffer, već da za izračunavanja, odnosno GPGPU koristi istu memoriju kao i CPU.

Dakle, sada i sam GPU može da primi „page fault“ jer pristupa memoriji preko MMU-a, što predstavlja korak u približavanju GPU-a i CPU-a po pitanju programabilnosti. Zahvaljujući tome što GPU deli MMU (Memory Management Unit) sa CPU-om, omogućen je pristup memoriji kroz kernel operativnog sistema. Za developere ovo znači daleko manje posla prilikom pravljenja softvera i implementacije algoritama za izvršavanje putem GPU-a.

Lepota ovakvog rešenja leži u tome što nije potrebno kopiranje podataka iz sistemskog RAM-a u GPU RAM i obrnuto, već se sve nalazi na jednom mestu, a raspodela se vrši sistemski, preko „user mode-a“, a ne „divljački“. Osim što je jednostavnije raditi sa ovako organizovanom memorijom, ovakav način rada dozvoljava korišćenje „zavadi pa vladaj“ algoritamskih strategija, gde CPU i GPU konkurentno rade na deljenoj strukturi podataka.

OpenCL 2.0 sa HSA podrškom znatno smanjuje posao programerima GPGPU aplikacija. Zapravo, programerska logika i način rada je gotovo identičan kao i kod najnormalnijeg C++ kodiranja. Za potrebe pretrage binarnog stabla, izbegnuto je pretvaranje strukture stabla u niz, kao i kopiranje ovako konvertovane strukture u lokalnu GPU memoriju.

Zahvaljujući ovome, ubrzanje u radu sa strukturama podataka kao što su binarna stabla je značajno ubrzano.

CPU callback je česta pojava kod heterogenog procesiranja. Na primer, ukoliko je GPU završio neki thread i potrebni su mu novi podaci za obradu, zbog kopiranja podataka moguća je lošiji stepen iskorišćenja GPU-a, a dodatno kašnjenje se ogleda u padu performansi. Kod HSA, taj problem je jednostavno rešen, CPU i GPU koriste isti adresni prostor, nema potrebe za kopiranjem podataka, pa iako je CPU callback izvršen, čekanja na podatke nema, jer su oni već tu, GPU najnormalnije nastavlja rad sa svojim punim potencijalom.

Punu podršku za HSA imamo već sa OpenCL 2.0, a krajnji korisnici će osetiti snagu Kaverija tek kada se HSA podrška odomaći kroz korišćenje novijih verzija GPGPU SDK-ova.