Keresés: - [Re:] Nagyon komoly újításokat hoz a shader modell 6.6

Legfrissebb anyagok

PROHARDVER! témák

Mobilarena témák

IT café témák

GAMEPOD témák

LOGOUT témák

Keresés

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

#18 Abu85 HÁZIGAZDA dabadab #17

Új Válasz 2020-11-30 11:36:24 #18
Ú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 dabadab #17 üzenetére

A mai GPU-kban statikus erőforrás-allokáció van, vagyis a regiszterek és az LDS tekintetében a shader fordító egyszerűen betöltet mindent. Ez a program oldaláról csak annyiban kontrollálható, hogy a regiszternyomást mennyire optimalizálják, de ennél direktebben ebbe nem tudnak beleszólni, nem elég okosak hozzá a mai hardverek.
Nem tudtam, hogy a Microsoft az senki. Köszi a felvilágosítást.
"min16float"
Az újabb HLSL verziókban már jól működik.
A régebbi nyelv, a 2019-es HLSL verzió előtt, amit még az FXC-hez terveztek ugyan kellettek trükkök, hogy ne 32 bites legyen az alignmentálás, de elég egyszerűen megoldható volt.
Kellett egy CPU-oldali kód, ami uintbe csomagolta a konstans és pufferadatokat, és ezek kezelhetővé váltak a GPU oldalán két sor kód beírása után. Másképp ugye aligha futott volna például a TressFX a játékokban, hiszen az exkluzívan packed mathot használt FP16-ra.
Ma már ezek nem kellenek, a Microsoft megoldotta ennek a támogatását trükkök nélkül is.
#15 Abu85 HÁZIGAZDA dabadab #14

Új Válasz 2020-11-26 12:19:35 #15
Ú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 dabadab #14 üzenetére

Hát mik tárolják? Pufferben vagy textúrában vannak. Mindkettő erőforrás.
Packed math eddig FP16-ra volt. Int8 natív vagy mixed módban volt, de nem packedben.
Hát miről? Béláról?
Te tudod? Én azért jó négy oldalt írtam erről korábban. [link] - ettől az oldaltól kezdve.
Maga a meghatározás azért fontos, mert a modernebb hardverek, mint az RDNA, már nem csak egy wave-méretet támogatnak hatékonyan, hanem kettőt is. Arról a shader fordító dönt, hogy egy shadert hogyan fordít le. Viszont a shader model 6.6-től kezdve a fejlesztő megmondhatja, hogy a shader fordító 32 vagy 64 lane-es wave-et használjon az RDNA-n például. Más hardveren ennek sok értelme nincs, mivel a min és a max wave-méret megegyezik, de nyilván ez egy jövőnek szánt funkció, egyre több hardver lesz olyan, mint az RDNA, így hosszabb távon a multiprocesszorok többféle wave-mérettel is hatékonyan tudnak majd működni.
#13 Abu85 HÁZIGAZDA dabadab #11

Új Válasz 2020-11-26 11:26:50 #13
Ú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 dabadab #11 üzenetére

A szintűt kivettem, ha ennyire zavar.
A lebegőpontos értékeket erőforrásokban tárolják.
Senki sem írta, hogy a packed math új.
Pont az a lényege, hogy ezt megadd, mert amúgy a meghajtó fordítójának szabad keze van benne.
Vagyis egy paraméter legyen meghatározva, hiszen egyetlen egy wave-méret jó a shadernek. Ha több is jó, akkor felesleges attribútumról van szó, hiszen a fordító jobban tudja, hogy mi a jó a hardvernek.
#6 Abu85 HÁZIGAZDA

Új Válasz 2020-11-25 18:48:31 #6
Ú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

TL;DR... jobb lesz.
#4 tibaimp : Hát ha minden képességet nem is, de az erőforrások dinamikus bekötését a GCN2+, az RDNA összes, a Turing összes, az Ampere összes, illetve a gen9+ biztosan támogatja. De szerintem, amire van TIER_3-as binding, arra rá lehet emulálni.