Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Mozno sa spytam blbo ale ako z toho lezie obraz ? Chapem ze to renderuje niekde offscreen do pamete kde je ulozeny aktualny screen buffer a co dalej ? Dany frame sa posle cez PCIx niekam povedzme cez siet na cieloveho klienta kde sa zobrazi ?
Dokázal bych si to představit ve spolupráci s např. RemoteFX. Tam už jakás takás virtualizace funguje.
http://diit.cz/clanek/vyzkouseli-jsme-remotefx-na-windows-serveru-2012
Tak zkoušet to na AMD grafice, která neni podporovaná, neni uplně dobrej nápad
Já občas provozuju Splashtop, na desktopu bez virtualizace, běží to rovnou akorát se prostě streamuje obraz a v hezkejch FPS i přes wifi ikdyž tam se musim krotit s rozlišenim samozřejmě
Tohle neni o GPU - zobrazovaci jednotka, ale o GPU - vypocetni jednotka. Takze obraz neleze nikam, pokud ho nerenderuje OpenCL program a ten uz si sam musi rict, kam ty data maji lezt.
No ano, netvrdim ze to nema vyuzitie, minimalne to umozni lepsie vyuzit nevyuzity vykon a skalovanie. Len ten kto pouziva masivne GPU na vypocty vecsinou ma nejake farmu prave koli tym vypoctom. Fakt netusim ci az tak je dolezita v takom pripade virtualizacia a zdielanie vykonu. Pri klasickom cpu sa to hodi lebo mozem poskytovat viacerim klientom vykon prave vdaka virtualizacii. Ratanie na GPU mi pride stale dost specificko zamerane na to aby si to prenajimali bezny zakaznici tak ako cloudove servery. Inak povedane ten kto ma na vyvoj systemu ktory rata cez GPU a potrebuje vela ratat tak uz vecsinou ma aj na to postavit si vlastny hw. Iste asi bude efektivnejsie si to zelezo len prenajat a nemusiet sa starat o spravu.
Ihmo neni, GPU budou stejně vyloadovaný svym GPGPU kódem tzn moc volnejch prostředků jim v typickejch výpočetních nezbyde, resp pokud bude práce dobře rozložená tak žádné. (pokud na GPu naložíte takovj litecoin miner neni schopné vám plynule přehrát ani film, tak moc je loaded.
Toto se uplatní ve 2 případech, jednak kdy víš že nebudou full loaded a chceš ze systému vytlačit všechen výkon, něco jako HT u CPU, tam ale stačí i řešení NV, více jak 8 úloh najedou (většínou více jak 2 najedou) nedává moc smysl. Resp by mohlo kdyby jedna zatěžovala třeba jen SP a druhá jen DP, což ale u dnešních GPU stejně přetíží shader cache a výkon jde do kopru. A u AMd s timhle novmy shedulingem by nemusel, ale Fiji má zas jalovej výkon v DP takže co z toho...
Kde by se to mohlo nejvíce uplatnit je když onen výkon chceš pronajímat, ala lidi si prostě zaplatěj určité množství gigaflopů na určitejch GPU. K tomu je také dobré to že AMD říká " stable, predictable performance. " Tzn můžeš prodat konkrétní výkon. To doteď možné nebylo, Doteď když se spustilo více věcí tak se praly o resources a nešlo garantovat výkon procesu A protože záležel na tom co dělá proces B.
Docela by mě zajímalo jak toho AMD dosahlo, pravděpodobně tak že GPU uvnitř se dokáže komplet rozdělit, určité bloky si dovedou vyhradit vše od čsti sběrnice až po díl Vram aby jim do práce nezasahovalo nic jiného co jede jinde v čipu, jinak si to nedovedu vysvětlit, jak jinak by šel garnatovat výkon.
Jak už bylo řečeno, neleze z toho obraz, slouží to pro výpočty. Uvedu několik příkladů :
Máš třeba citrix farmu a uživatelé se přihlašují s tenkými klienty na server
- podpora GPU virtualizace umožní, že třeba při práci v nějakém CADu se mu vykreslí obraz sakra rychle (pokud CAD podporuje akceleraci přes GPU) a přes citrix pošle ke klientovi. V opačném případě by se o vykreslení / výpočet muselo postarat CPU, čímž by docházelo k nepěknému zatížení celé farmy
- nebo jen blbý flash. V současné době citrix podporuje to, že se třeba flash vykresluje na straně klienta. Když máš ale tenkého klienta, tak můžeš mít docela velké problémy s výkonem. V případě virtualizace GPU se nebudeš muset bát nechat vykreslovat flash na straně serveru a ke klientovi přenášet jen obraz.
Dále je to další krůček k bezpečnosti a izolaci. Já to vidím tak, že jednou budeme mít na PC jen malý hypervisor, nad kterým nám bude moci běžet několik VM současně (nebo co VM, to jedna app), budou plně oddělený, v případě nějakých problémů obnovíme snapshot a jedeme dál. Spousta z toho je už dnes možná, ale spousta toho ještě možná není (zatím se věci řeší dedikací celé karty pro VM, což je neúsporné a má to své značné limity). Nvidia podporuje vGPU (a Xen/ESXi/Citrix s tím umějí pracovat), ale jak už bylo nastíněno, je tam ještě značný prostor pro zlepšení.
Zdar Max
Nejspis to bude chytra nadstavba nad async shadery. Jsou nezavisle, takze se muzou oddelit i z pohledu pristupu ke karte. Karta poskytne hypervisoru nejaky zpusob virtualizace a ten ji muze rozdelit na casti a kazdou podstrcit jednu VM pomoci VT-d. Vyhoda proti vGPU je v tom, ze hypervizor vubec nemusi zajimat rizeni karty a OS ve virtualu vubec nemusi zajimat, ze dostal je virtualni slice karty.
Pokud se jim podari dostat rychle podporu do KVM a Xenu, tak muzou docela zamichat s nakupem profi karet pro cloud/virtualizaci, kde ted vladne nVidia. Jen to opravdu nesmi zbabrat na strane SW.
Je to zajimave, ze kdykoliv prijde s necim nVidia, je to jejich vlastni napad nekompatibilni se vsim ostatnim, a kdykoliv prijde s necim AMD, je to otevreny standard ...
... a pak maji 18% trhu....
Myslim ze par lidi potrebuje pochopit, ze business nedelaji otevrene standardy "zdarma", ale kvalitni a fungujici reseni s profesionalni podporou. Proto je profi sekce AMD ve stavu klinicke smrti uz deset let.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.