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

• #34555 Abu85 HÁZIGAZDA Petykemano #34554

  Új Válasz 2018-08-12 13:51:13 #34555

  Ú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 Petykemano #34554 üzenetére

  A sugárkövetés alapvetően nem egy tensorban megvalósítható dolog. Az FP32-es számítás, ráadásul a DXR aktuálisan érkező verziója 32 bites vertex formátumot támogat csak, vagyis ha nem butítasz nagyon a geometriai részletességen, akkor 10+ GB VRAM a belépő. A második DXR verzió fog több vertex formátumot támogatni, de az leghamarabb jövő tavasszal jön, de az is lehet, hogy csak egy év múlva, mert rengeteg más szempontból is változás lesz a DXR-ben, ami már eleve megtöri a kompatibilitást, tehát célszerű, akkor egyben újrakezdeni.
  A fixpontos dot product a denoising szempontjából előnyös a DXR-ben, de ott is valami szabályozást akar az ipar, mert az AMD például már bejelentkezett a 4 bites megoldásával, amit a DXR specifikáció elfogad, de az NV szerint kellene egy minimum érték. Nekik ugye 8 biten kell ragadni a hardverük miatt, ami azt jelenti, hogy az AMD sokkal gyorsabb lesz a Vega 20 4 bites formátumával. A 8 bites fixpontos dot product egyébként egy reális szabvány lehetne, de mivel az AMD-nek már van 4 bitre is alkalmas hardvere, így csípőből ellenezni fogják, vagyis leginkább annak van most realitása, hogy az NV és az Intel is elkezd vadul menni a 4 bites formátumra.
  Jelen pillanatban a DXR mögött rengeteg a kérdés. Már csak a hardver oldali implementáció miatt is, mert a Microsoft nem nagyon akarja szabályozni ezt, ők úgy vannak ezzel, hogy adnak egy specifikációt, aztán nézik a végeredményt. Azt nem igazán akarja a cég meghatározni, hogy a végeredmény előtt mit csinálhat a hardver. Az MS szempontjából akár varázsolhat is, ha a végeredmény megfelel a követelményeinek. Az NV azonban szabályozást akar, méghozzá úgy, hogy a Microsoft kötelezően írja elő, hogy fixpontos dot product számításokat egy külön ALU-csoport végezze. Ebbe például az AMD és az Intel helyből nem fog belemenni, mert ők például ellenzik ezt a megoldást, ugyanis ha így lenne meghatározva a specifikáció, akkor tranzisztorok milliárdjait költenék egy olyan részegységre, amely grafikai szempontból csak egy specifikus működés mellett hasznos, máskor pedig csak a helyet foglalja. Ezzel szemben az AMD és az Intel a fő ALU-kba építi bele a fixpontos dot product támogatást, vagyis ha erre nincs szükség, akkor azok a tranyómilliárdokat elfoglaló ALU-k mást számolnak. Az NV-nek érthető, hogy ez miért nem tetszik, a architektúrájuk ilyen formában hátrányba kerül, mert ha egy játék nem használ majd DXR-t, akkor semmit sem fog érni a hardverben található rakás fixpontos dot product ALU. Ráadásul a denoising esetében a Microsoft nem igazán határoz meg semmit. Emiatt az AMD lehet, hogy nem is DL TOPS-szal implementálja, hanem SAD/QSAD/MQSAD megoldással, amit visszamenőleg meg tudnak oldani az összes GCN-re.

  A másik probléma ebből a szempontból a Vulkan API. Amire szintén van egy nagyon érdekes sugárkövetési megoldás. És ott az a fő gond, hogy azt az AMD írja, és nem egy szabványalkotó. Ráadásul nem lehet megcsinálni driverben azt, hogy ezeket a feladatokat a hardver ne futtassa le, vagyis az NV és az Intel is kénytelen elviselni mindazt a terhet, amit az AMD saját megoldása rájuk rak. És a DXR-hez képest a Vulkan AMD-s megoldása nem az API kiegészítése, hanem egy API feletti réteg, így a meghajtó oldalán nem befolyásolható, úgy fut a program egy hardveren, ahogy az AMD akarja. A DXR ebből a szempontból sokkal általánosabb, hiszen a Microsoft lehetővé teszi a saját fallback layerét, illetve a gyártó bármikor írhat rá drivert, amiben sok dolgot befolyásolhatnak. Ilyen formában a DXR nem igazán veszélyes, mert specifikált megoldás, amit egyenrangú felekként támogathat minden IHV. A Vulkan feletti Radeon Rays sokkal veszélyesebb, mert még ha a Volta tudná is futtatni sokkal hatékonyabban, akkor sincs meg az az úgymond híd, amivel ezt meg is tudják valósítani.

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