Új hozzászólás Aktív témák

• #10267 Abu85 HÁZIGAZDA rocket #10248

  Új Válasz 2015-09-11 18:29:23 #10267

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz rocket #10248 üzenetére

  Nem az AotS kapcsán volt róla szó. Az async DMA és compute egy olyan dolog, amit a konzolra dolgozó fejlesztők jó ideje használnak. Tehát semmi újdonság nincs benne, csak PC-re még nem használták sokan (csak a Thief). Elsődleges célja, hogy ingyenessé tegyen bizonyos számításokat, mert ezeket a hardveren belüli buborékokra rá lehet ütemezni. Például shadow mapoknál a shader feldolgozók 90%-a NOP-ot futtat, vagyis nem csinálnak semmit, csak várják, hogy végezzen a ROP a számítással. Ezekre a feldolgozókra ki lehet osztani feladatokat, amelyek addig végeznek, amíg a shadow mapok számítása zajlik. Ergo a teljes számítás, amit ezekre kiosztottak gyakorlatilag ingyenessé válik. Számolt a rendszer egy csomót, de közben kvázi semmit sem lassult a tempó, mert a shadow map számítása tovább tartott így is.
  A multi-engine ezeknek a hardveren belüli idle buborékoknak a betömésére jó.
  Aztán ott a gyakorlat, hogy ezt ki hogyan használja, mert egészen sok lehetőség adódik azzal a modellel, amit a DX12 lehetővé tesz. Nem muszáj buborékokat tömködni, akár elindítható több alacsony prioritású compute feladat is a grafikai feladatok mellett. Valószínűleg a Nitrous eleve egy nagyon kiegyensúlyozott motor, így nem sok buborékot lehet betömni, ami miatt inkább párhuzamos megközelítéssel dolgoznak a fejlesztők. De az valóban igaz, hogy a motorok 99%-a a Nitrous teljesítményének a töredékét sem képes hozni, és így logikus, hogy jóval több idle buborékok lesz a hardvereken belül. Így például ezeknél a motoroknál lehet más megközelítéssel is élni. Írtam az ezzel kapcsolatos cikkben, hogy az NV valószínűleg azért nem tiltja le csípőből ezt a képességet, mint az Intel, mert egyrészt szeretnék használni az async DMA-t, másrészt nagyon valószínű, hogy van olyan megközelítés, amitől a Maxwell 2 is gyorsul, mert valószínű, hogy a compute bizonyos grafikai state-ekre épül. Bár a Maxwell 2-ről nincs dokumentáció, de nagyon jellemző, hogy stateful hardvereken a compute és a pixel feladatok ugyanazokat a state-ket használják. Nyilván, ha az NV azt gondolná, hogy a fejlesztők nem képesek olyan kódot írni, ami a hardverükön gyorsul, akkor nem is gondolkodnának a multi-engine hardveres kezelésén.

  Az meg teljesen normális, hogy egy fejlesztő letilt dolgokat, bizonyos alternatív kódrészletekkel, ha az adott implementáció nem felel meg az adott hardvernek. Pontosan ezért van a Nitrousban egy NV-re kialakított kódrészlet a fő programkód mellett. Ez nem tudom, hogy miért újdonság, hiszen lassan egy évtizede folyamatosan alkalmazott praktika.

Új hozzászólás Aktív témák