Hirdetés
- StarCraft hírek: Készülhet egy új játék, miközben Game Pass-be tart a széria
- Unknown 9: Awakening - Amit a játékról tudni érdemes
- Jövő hónapban Xboxon is kipróbálható lesz a Fragpunk
- Újabb kedvcsinálón a The Last of Us TV sorozat második szezonja
- Újabb játékmenet videót kapott a Dragon Quest III: HD-2D Remake
-
GAMEPOD.hu
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
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
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen