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

• #15518 Abu85 HÁZIGAZDA szasanyi #15497

  Új Válasz 2013-01-03 23:30:46 #15518

  Ú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 szasanyi #15497 üzenetére

  Mindegy, hogy mit tud a Kepler, vagy a GCN. A forward+ lighting nem azért került a DiRT Showdownba, mert a Codemasters ki akart bacni az NV-vel, hanem azért, mert szükségük volt rá, hogy hatékonyan kezeljenek egy rakás pontfényforrást. Bármennyire hihetetlen ebből a Kepler és minden más architektúra profitál, és nem csak a GCN. Persze a GCN-en a leggyorsabb, de a fejlesztő azt fogja nézni, hogy a forward+ lighting a hagyományos forward renderhez képest többszörösen gyorsabb. Ezzel már neked jót csinált, mert nem 4-5 fps-sel fut a játék, hanem 30-40-nel.
  A deferred rendereknek is megvannak a nyűgjei. Például az MSAA. Mit kínál rá az AMD? Egy compute shaderes MSAA-t, ami először elemzi a képet, majd kijelöli, hogy hol van értelme futtatni a deferred MSAA kódot. Ez is a GCN-en a leggyorsabb, de a fejlesztő megint azt fogja nézni, hogy nagyjából ugyanolyan jó eredmény mellett az elemzős megoldás 10-70%-kal gyorsabb mindenen, függően a képkockától. Ezzel megint neked csináltak jót.
  Ugyanígy a legnagyobb probléma ma az átlátszóság kezelése. Régen nem volt ez gond, mert forward render mellett nincs kivágva a felület, így azok le lesznek renderelve. Deferred renderrel egy ablak mögül még azelőtt eltűnik a poligon, mielőtt kiderülne, hogy az az ablakból látszik. Ilyenkor kell egy speciális rutin, hogy az jól legyen megjelenítve. A fejlesztőnek sorrendbe kell rakni az objektumokat, így jól visszakövethető, hogy mi az ami látszani fog, de kivágta a render. Aztán lehet renderelni és ennyi. Persze ez még mindig nem problémamentes. Ilyen hibák előfordulhatnak, ha nem tökéletes a sorting. [link] - látható, hogy az elől lévő ablaknál, ahol a csaj ül a gép ajtaja nincs kirajzolva, de a másik ablakban meg ki van. Alternatíva az OIT, itt nem számít a sorrend, mert az elv, hogy ne legyen felállított sorrend. A GPU compute shaderrel meghatározza, hogy mi látszik és mi nem. [link] - ezzel a gond megszűnt. A deferred render motorokhoz az AMD már kínál egy forward+ tack-on algoritmust OIT-vel, ami sokkal jobb ezekben a szituációkban, mint rendezgetni, majd esetleg hibát keresni a rendezésben, ha nem jó. OIT-vel még a dizájn szabadság is sokkal jobb lenne. [link] - az ilyen komplex helyzetek bármiféle komoly odafigyelés nélkül leképezhetők, mert az algoritmus figyel a problémákra. Itt sem azt fogja nézni a fejlesztő, hogy jaj ezt compute shaderben megoldva fájni fog a Keplernek, hanem azt, hogy jobb lesz a grafika, megmenti magát sok limitációtól, illetve általánosan gyorsabb megoldás minden hardveren.
  Ezek a problémamegoldásról szólnak. Van probléma? Nagyon is. Van megoldás? Jelentős részükre igen. Gyorsabb minden hardveren a megoldás? A tradicionálisnak tekintet megvalósításoknál az. Innentől kezdve a Kepler és a GCN viszonya fel sem merül. Mindkét architektúra profitál ezekből, csak a GCN jóval többet.

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