2017. november 24., péntek

S​zp​o​nz​orunk

Klixnetwork.huKlixnetwork.hu

Az AMD részletezte a Vega 10 virtualizációs képességeit

  • (f)
  • (p)
Írta: | | Forrás: PROHARDVER!

Lényegében csak ez az információ hiányzott a teljes képhez, és ezt a Hot Chips szállította is.

Az AMD Hot Chips rendezvényen a Vega 10-nek szentelte az előadását. Erről a lapkáról rendkívül sok információ derült ki az utóbbi időben: a játékosokra vonatkozó elméleti oldalról az alábbi cikk első hét oldalán számoltunk be részletesen, de nyilván más területeket is céloz a termék. Az egyik ilyen a GPU-s virtualizáció, amely majd a szeptemberben érkező Radeon Pro WX9100 és Radeon Pro SSG modellek sajátossága lesz.

Még mielőtt a Vega 10 virtualizációra vonatkozó újításait részleteznénk, érdemes elemezni azt, hogy mit kínálnak ma az érintettek ebből a szempontból, különben az újítások csak úgy állnának a levegőben, és nem lehetne őket viszonyítani semmihez.

A GPU-s virtualizációra az AMD, az Intel és az NVIDIA is kínál megoldást rendre MxGPU, GVT-g és vGPU néven. Az elnevezések ráadásul igen eltérő megoldásokat rejtenek, mivel többféle megvalósítása van a munkaasztal virtualizációjának, és látni fogjuk, hogy az említett cégek nagyon nem ugyanazt az utat járják. Ettől függetlenül a Hypervisorok hitelesítés szempontjából egyre jobb a helyzet, ahogy az várható volt a támogatás mindhárom vállalatnál egyre csak bővül. Az AMD az ESX és a Xen, az Intel a KVM és az ESX, míg az NVIDIA az ESX, a Xen és a KVM opciókhoz kínál meghajtót. Ez a jövőben minden bizonnyal tovább fog bővülni.

Az igazi eltérés a cégek között a virtualizáció megvalósítása, és ebből a szempontból az alábbi táblázat ad bővebb felvilágosítást:

A GPU-s munkaasztalra vonatkozó virtualizációk formái
Virtualizált részegység
NVIDIA vGPU
Intel GVT-g
AMD MxGPU
Multiprocesszorok
függetlenített időosztásos
szinkronizált időosztásos fizikai felosztású
Videodekódoló blokk
függetlenített időosztásos szinkronizált időosztásos nincs / automatikus
Videokódoló blokk
függetlenített időosztásos szinkronizált időosztásos nincs / automatikus
Videomemória
fizikai felosztású fizikai felosztású védett fizikai felosztású
GPGPU támogatás
limitált (pass-through)
teljes teljes
Hypervisor menedzsment szoftveres
szoftveres
hardveres (SR-IOV)

A táblázatból látható, hogy az NVIDIA és az Intel szoftveres módszert használ a menedzselésre, míg az AMD hardverest. Igazából ez a fő különbség, mert minden más fontosabb eltérés lényegében ebből ered. A hardveres, SR-IOV menedzsment teszi lehetővé a multiprocesszorok fizikai felosztását, vagyis az adott GPU-hoz rendelt virtuális gépek valós időben elérhető erőforrásokat kapnak. Tulajdonképpen ez egy BIOS szinten üzemelő konstrukció, lényegében az egyetlen GPU-val dolgozó hardvert a rendszer úgy kezeli, mintha fizikailag több GPU lenne.

Az NVIDIA és az Intel konstrukciójával az elérés nem valósidejű, hanem időosztásos, vagyis egy adott virtuális gép egy meghatározott ideig használhatja a teljes GPU-t, majd jön a következő virtuális gép, és így tovább, amíg körbe nem ér a rendszer, majd kezdődik elölről. Az NVIDIA és az Intel megoldása között azonban itt is van eltérés, ugyanis a GVT-g szinkronizálja az időosztást a multiprocesszorok és a multimédiás blokkok között, vagyis például egy virtuális gép akkor is megkapja az utóbbi részegységeket, ha azokat nem is használja. A zöldek vGPU-ja ebből a szempontból jobb, mivel az időosztás függetlenített, vagyis egy virtuális gép csak akkor kapja meg a multimédiás hardvereket, ha igényt tart rájuk. Ez egy logikus döntés az NVIDIA részéről, mert felesleges kiosztani az egyes részegységek elérést olyan virtuális gépeknek, amelyek amúgy sem futtatnának semmit ezeken, függetlenítve viszont hamarabb elvégezhetők azok a feladatok, amelyeket a többi virtuális gép igényelt.

A videomemória szempontjából mindegyik rendszer fizikai felosztást alkalmaz, itt nincs is nagyon más mód, viszont az AMD védett rendszerrel dolgozik, vagyis egy virtuális gép mindig csak a saját memóriaszeletéhez fér hozzá, a hardver ugyanis minden más memóriaelérést megakadályoz. Ez főleg biztonsági szempont, ugyanis a Intel és az NVIDIA megoldásával megvannak a módjai annak, hogy az adott virtuális gép számára készített képkockákat kinyerhesse egy illetéktelen felhasználó. Ez a szoftveres menedzsment nagy hátránya, és emiatt az Intel, illetve az NVIDIA gőzerővel vadászik a biztonsági résekre, annak érdekében, hogy illetéktelen adatszerzéssel egy meghatározott szoftverhibából eredően csak limitált ideig lehessen élni.

A GPGPU támogatása tekintetében az NVIDIA megoldása az úgynevezett pass-through módot támogatja, vagyis ilyenkor az igényt kiadó virtuális gép teljesen kisajátítja a GPU-t, így a többi virtuális gép addig nem kap új képkockát, amíg a GPGPU-s munkafolyamat le nem fut. Ha ez sokáig tart, akkor igen hosszú ideig kvázi használhatatlan lesz a többi virtuális gép. Ez a munkafolyamat ugyanakkor nem minden virtualizált környezetben releváns, sőt igen ritkának mondható. Mindezek ellenére az Intel és az AMD teljes értékű támogatást kínál a GPGPU-ra, tehát például egy OpenCL program úgy futhat egy adott virtuális gépen, hogy az nem befolyásolja a többi virtuális gép megszokott működését.


[+]

Az AMD multimédiás blokkjainak virtualizált elérésére szándékosan nem tértünk ki, ugyanis ebből a szempontból hoz újítást a Vega, és nagyrészt erről szólt a Hot Chips előadás is. A korábbi hardverekkel az MxGPU nem tette hozzáférhetővé a videodekódoló és -kódoló blokkokat, így ez volt a rendszer gyenge pontja. A Vega 10 viszont teljesen virtualizált UVD-t és VCE-t kínál. Ezek eléréséről teljes egészében a hardver dönt, vagyis semmiféle szoftveres menedzsment nem szükséges hozzá. A működés alapja, hogy a GPU fizikailag felosztott szeleteit elérő virtuális gépek adhatnak le igényt az UVD és a VCE használatára is, és ilyenkor a hardverbe épített ütemező automatikusan hozzárendeli az adott részegységet, vagy – nagyobb terhelés mellett – annak csak egy részét az adott munkafolyamathoz.


[+]

Az AMD szerint a Vega 10 virtualizációs újításai kifejezetten hasznosak lesznek az olyan felhős szerverközpontokban, ahol különböző grafikus és GPGPU-s API-kon keresztül működő alkalmazások futtatására bérelhet hardvert a felhasználó. Ilyen például a felhős játék, de ez csak egy példa. A probléma ugyanis a korábbi rendszerekkel az volt, hogy egy felhasználónak egy teljes GPU-t kellett kiosztani. És ezt akkor is meg kellett tenni, ha a hardvernek elenyésző részét használta. Ezáltal egy nagyobb szerverközpontot pontosan annyi felhasználó tartott fent, ahány GPU volt a szerverben, ami végeredményben az adott szolgáltatás magas költségeihez vezetett. A Vega 10-et használva elérhető az is, hogy egy szervert akár 16-szor több felhasználó tartson fent, mint ahány GPU van a rendszerbe építve, vagyis úgy csökkenthető a szolgáltatás ára, hogy közben nő a realizálható nyereség.


[+]

Végül a Radeon Instinct MI25 is érkezik külön megvásárolható formában, így az AMD kiemelte, hogy a hozzá való ROCm szoftvercsomag és a MIOpen könyvtár is támogatja már az Vega 10 GPU-t.

H​irdet​és​

Gyártók, szolgáltatók

H​ir​de​t​é​s​

Copyright © 2000-2017 PROHARDVER Informatikai Kft.