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

• #40689 Abu85 HÁZIGAZDA Raggie #40686

  Új Válasz 2019-05-13 13:47:58 #40689

  Ú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 Raggie #40686 üzenetére

  Az idei explicit API-s felhozatalból szinte mindegyik. De már az előző év végére is ez volt a jellemző. Azért csinálják ezt a fejlesztők, mert az AGS fordítója nagyrészt érti a PSSL shadereket, tehát ezeket nem kell újraírni, hanem van egy konverter, amibe beküldöd, és kiadod HLSL Ext. shaderként, amivel máris tud bánni az AGS valamelyik verziója.
  A különbség most annyi lett, hogy a jövőben ezt valószínűleg nem AGS-sel képzeli el a piac, mert az alapvetően csak az AMD-nek előny, de maga a wave terminológia általánosan hasznos. Erre van a shader modell 6 és a Vulkan API-n belül a subgroup shaderek. A shader modell 6-ot még wave terminológiára nem használják, de Vulkan API-ra már ott a World War Z, ami subgroup shadereket is használ. Emiatt kavarodott össze az utóbbiban az erősorrend, mert a subgroup/wave terminológia (ugyanaz mindkettő, csak máshogy hívja a Microsoft és a Khronos) eltérő módon működteti a hardvereket a régi, soros feldolgozáshoz képest. Egészen konkrétan megadja annak a lehetőségét, hogy az egymástól független párhuzamos feladatok bármilyen módban párhuzamosan fussanak a multiprocesszoron belül, és meg tudják osztani egymással az adatokat, legyen szó bármilyen pici feladatról. A korábbi terminológia erre csak compute shaderben adott lehetőséget, és ott is csak a helyi adatmegosztást lehetett használni az adatok megosztására, de csakis a helyi munkacsoportok között, vagyis maga az adatmegosztás durva szemcsézettségű volt.
  Látszatra ezek nem tűnnek nagy különbségnek, de valójában azok, mert a hardvernek vannak különböző állapotai, amelyeken belül a multiprocesszor némileg eltérően működik, és nehéz meghatározni, hogy egy ilyen váltásra a korábbi terminológiához tervezett hardverek hogyan reagálnak. Maga az architektúra fejlődik az AMD és az NV dizájnjaiban, de az ISA tekintetében az alap az AMD-nél még az öreg GCN, míg az NV-nél a szintén öreg Fermi, tehát amikor ezeket tervezték 2010-nél korábban, akkor nem nagyon volt szempont, hogy 2019-re mennyire változik meg a shader modell. Ezt igazán lekövetni új ISA-val lehet, de mivel a hardveres szálkezelés tekintetében még mindig nincs ott a GCN és a Fermi, hogy a limitek erősen látszódjanak, így egy darabig nem valószínű, hogy az AMD és az NV vált. 2020 után tuti, de az még később van.
  DirectX 12-re támogatást lehet írni egy eredetileg DirectX 9-re tervezett játékra is. Nem éri meg, de ettől lehetséges. A régebbi leképezők alapvetően tudnak működni nagyon sok API-n. Vannak bizonyos leképezők, ahol már nagy hasznot hoz mondjuk a DirectX 11, vagy a 12. Előbbire tipikus példa szokott lenni a compute cullingos megoldások, amikor valami problémát compute shadereken keresztüli kivágással kezelsz, míg utóbbi leginkább akkor hasznos, ha maga az árnyalás a jelenet szintjén történik, és nem a fragmentek szintjén, ez ugyanis jelentősen növeli a rajzolási parancsok számát, hiszen már nem lesz erősen limitált a shadow casting fényforrások száma sem, és rengeteg effekt szimplán a jelenet szintjén megoldható, egyszerűen csak másolod az árnyalt objektumokat. Annyiszor tudod ezeket megjeleníteni, amennyi rajzolási parancsot költesz rá, a hardver csak egyszer számolja ki.

  (#40687) Raymond: compute-based triangle filtering

  (#40688) gbors: A wave/subgroup shadereknél eléggé össze van keverve az erősorrend. Sok múlik a fordítón, illetve azon, hogy az adott program milyen intrinsics függvényeket használ, a 2010 előtt tervezett ISA-k mennyire rugalmasak ebből a szempontból, mert ezeken olyan sokat javítani nem lehet, maximum teljes újratervezéssel. Ezért baj itt tippelgetni, mert a World War Z Vulkan módja ugyan egyértelműen első fecske, de egy rakás olyan tényező van, amit még húsz fecske után sem fogunk igazán ismerni. Tehát a World War Z Vulkan módjából annyi vonható le következtetésként, hogy azokkal a subgroup shaderekkel, amiket a program használ, azokkal a hardverállapotokkal, amelyekben ezeket futtatják a GPU-k, azokkal a fordítókkal, amelyeket a gyártók jelenleg implementálnak, ez a teljesítmény. És a sok tényező miatt nem lehet azt mondani, hogy ez lesz a következő címnél is. Emiatt nehéz erre építeni. Simán lehet, hogy megfordul az egész, mert más kódokat kapnak a hardverek, más hardverállapotokban futtatják azokat, és máshogy fog működni a fordító. Régen ez azért volt sokkal egyszerűbb, mert ha adatmegosztás kellett a feladatok között, akkor arra egy mód volt, és erre a módra ki volt gyúrva a hardver (na jó a hardver nem mindig) és a fordító. Ma nagyon-nagyon sok mód lett erre, és ki tudja, hogy melyik állapotra van kigyúrva az adott hardver, és melyikre fordít hatékony kódot a fordító.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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