Budućnost je hUMA

Softverski deo – ukratko

AMD i „open source“ zajednica odavno već rade na bibliotekama za podršku za GPGPU procesiranje. AMD APP-AMD Parallel Processing biblioteka (bivša ATi Stream biblioteka) vam omogućava da na procesoru izvršite deo OpenCL koda, odnosno onoliko thread-ova koliko imate procesorskih jezgara i GPU izvršnih jedinica, odnosno stream procesora. Kombinacijom korišćenja procesora i GPU-a dobija se višestruko ubrzanje u OpenCL baziranim aplikacijama. Ovo je moguće zahvaljujući specijalno razvijenom kompajleru koji generiše ciljni kod i za GPU i za CPU. Dakle, razlika u izvršavanju postoji na hardverskom nivou, jer se CPU radikalno po arhitekturi razlikuje od GPU-a. Na kraju krajeva, poenta heterogenog procesiranja i jeste u tome da CPU „pomogne“ GPU u visokoparalelizovanim zadacima, odnosno da GPU „pomogne“ CPU u serijalizovanim operacijama.

Programski kod koji je generisan podržava visok stepen paralelizma podataka. Na procesoru se izvršava koristeći SIMD SSE2/3 i novije vektorske instrukcije. Na slici je prikazan lanac generisanja OpenCL koda uz pomoć AMD APP SDK.

OpenCL biblioteka sadrži kompajlerski deo koji se zove LLVM – Low Level Virtual Machine. Izvršni fajl koji je kompajliran koristi dinamički deo iz OpenCL biblioteke, koji vrši raspodelu izvršavanja na x86 procesor i GPU, preko odgovarajućeg drajvera. Primene OpenCL-a i GPGPU programiranja su mnogobrojne, počev od video enkodovanja i Ray Tracing-a, preko softvera za prepoznavanje lica, enkripcije i dekripcije podataka uz korišćenje AES, RSA, SHA i MD5 Hash algoritama, pa sve do digitalne obrade signala (izvršavanjem FFT – Brzih Furijerovih Transformacija-a – Folding@Home). U svim ovim primenama vrši se obrada nad paralelizovanim podacima.

Međutim, u klasičnom HSA sistemu (CPU + GPU) postoji „mali“ problem, a to je način pristupanja podacima u memoriji. Da podsetimo, procesor pristupa memoriji putem „paging“ sistema, što mu čini da je pristup višestruko efikasniji nego kod klasične linearne pretrage.

APU nudi mogućnost pristupa GPU memoriji putem prosleđivanja pokazivača (pointera) čime se štedi na bandwidth-u i u velikoj meri se dobija na brzini. Zero Copy i Pin-in-Place su praktično „APU only features“. Teksture se kreiraju u sistemskoj memoriji i kopiraju se u virtualnu memoriju. Kada sistem zahteva učitavanje teksture, prvo je traži u virtuelnoj memoriji, a onda je operativni sistem kopira u RAM, odakle se kopiraju putem PCI-express magistrale u GPU memoriju a samim tim omogućen direktan pristup GPU-u. APU nema potrebu da kopira delove memorije iz sistemskog RAM-a u framebuffer, zato što GPU i CPU dele istu memoriju. Zero Copy pristupa virtualnim memorijskim adresama direktno putem osvežavanja podataka o adresama u page tabeli i jednostavnom promenom pokazivača (pointera) na odgovarajuću memorijsku lokaciju, bez ikakve potrebe za kopiranjem. Poređenja radi, čitanje iz lokalne memorije kod APU-a odvija se brzinom od 15-20 GB/s, dok kod diskretne grafike, putem PCI-Express magistrale, kopiranje tekstura se vrši brzinom ne većom od 6 GB/s. Kod OpenCL primene, CPU čitanja iz framebuffera su veoma spora, jer ta memorija nije keširana – nije pod pagetable sistemom procesora, TLB ne kešira memorijske lokacije i pretraga ovog dela memorije je veoma spora. Pomoću ZC moguće je čitanje iz framebuffer-a jednostavnom promenom pointera. Ono što važi za teksture, važi i za podatke nad kojima se vrši obrada OpenCL programom. Odsustvo kopiranja iz virutalne memorije u framebuffer i obrnuto je naročita prednost kod APU-a, jer je memorijski prostor deljen. Ipak i dalje imamo problem, deo memorije rezervisan za GPU nije pod „pagetable“ sistemom, što znači da i dalje nije keširan i u slučaju pretrage GPU memorije, imaćemo veoma spor pristup.