Ú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.

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