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

• #30 Abu85 HÁZIGAZDA MCBASSTION #26

  Új Válasz 2012-08-14 11:17:16 #30

  Ú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 MCBASSTION #26 üzenetére

  Működni biztos hogy működik, hiszen ezért kutatják. De az implementálásnak jellemzően vannak nehézségei, és ezeket kapcsolatba hozhatjuk a hardverekkel. Amikor az egyes rendereket hasonlítjuk össze, akkor elő lehet jönni azzal, hogy ilyen, meg olyan készül, de a gyakorlati tények alapján az számít, hogy épül-e rá valami (jellemzően játékra gondoljunk, hiszen ez lenne a lényeg), és az hogyan működik a gyakorlatban.

  A forward renderhez készült clustered shading eljárás tényleg nagyon ígéretes. Ígéretesebb mint a forward+ lighting. És tényleg nagyon jó, hogy 3D-ben dolgozik, de ez nem csak a jobb hatékonysággal jár, hanem nagyobb erőforrásigénnyel is. Ha megnézed az eddigi egyetlen forward+ lighting játékot, akkor azon láthatod, hogy a GCN architektúra az egyetlen, ami jól érzi magát (mert az eljárás compute monster architektúrát igényel). A Kepler már eléggé szenved. Na most ezen még komplexebb compute shaderek nem segítenének. Emellett ahogy a forward+ lighting, úgy a clustered forward shading sem menne a jelenlegi konzolokon.
  Szóval én szeretem a minőséget, de jelenleg figyelembe kell venni, hogy a forward+ lightingot csak a GCN architektúra számolja gyorsan, és amíg az NV nem zárkózik fel, addig nem látom értelmét egy ennél is komolyabb compute terhelésnek, mert nem lesz futtatható Kepleren, ami gond. Főleg amellett gond, hogy a Keplert tartják most jobbnak, ami abból ered, hogy a régebbi játékok kevés compute shader terhelést adnak. Az újakban már egyértelműen látszik, hogy mi a helyzet, noha ezek közül is csak a DiRT Showdown, ami nagyon igényli a compute hatékonyságot.
  Egyelőre tehát nőjenek fel a hardverek a feladathoz. Ne csak az egyik, hanem mindegyik. Amíg csak a GCN elég compute monster, addig nem hiszem, hogy a fejlesztők annyira ránéznek ezekre a technikákra. A forward+ lighting is csak azért került elő, mert nagyon könnyen implementálható, és az eredetileg forward renderre épített motorok képességeit szépen felturbózhatja. A deferred render motoroknál is lesz egy forward+ "tack on" eljárás OIT-vel, legalábbis az AMD most ezen dolgozik. Ezzel a deferred render átlátszósággal kapcsolatos problémái megoldhatók, és az implementálás is könnyű. Ennek viszont van egy olyan hátránya, hogy nem csak a compute terhelés magas, hanem a memóriahasználat és a memória-sávszélesség terhelése is deferred MSAA mellett. Mindenesetre ez még az a határ, ami vállalható, mert nem fogja teljesen padlóra küldeni a Keplert, noha tény, hogy nem fog tetszeni neki a terhelés szintje és jellege. Persze sok függ az egyéb effektektől is, így forward+ "tack on" és OIT mellett azért érdemes gondolkodni azon, hogy a HDAO mellé legyen egy HBAO is, mert mégis 4,5x-es különbség van a Kepler és a GCN shared memory tempója között.

  [ 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