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

• #210 Abu85 HÁZIGAZDA Callisto #204

  Új Válasz 2012-01-01 15:18:27 #210

  Ú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 Callisto #204 üzenetére

  Nem bug van a BF3-ban. Az alkalmazott Deferred Render algoritmus zabálja a memóriát.
  Itt sok megoldás van, amit alkalmaznak a fejlesztők. A Defered Shading az, amikor a G-Buffer kimenetek között akár 6 fázis is lehet. Ez nagyon sávszélesség-igényes, de lehetővé teszi az virtuális anyag indexelését, ami sok információ tárolását jelenti pixelenként. Le is zabálná a legtöbb kártyát (a legtöbben kerülik). A Partial és a Full Defered Lightning kevesebb információt tárol, vagyis kevesebb a sávszélességigény, de a kevesebb információ miatt limitáltak a felületi variációk (mindenesetre jelenleg jobb alternatívák). Ha jól tudom, akkor a full, legjobb esetben 96 bit/pixel, míg a partial 64 bit/pixel. A Deferred Rendering esetén, olyan 130-140 bit/pixel elég lenne sok dologra, de nincs meg a sávszélesség. Ezekben ugye még nincs benne a Deep G-Buffer, amire az AA-hoz és az átlátszó felületekhez szükség van. Itt jön képbe a Repi ötlete a Frostbite 2-ből. Arra épít, hogy memória van bőven, vagy az árak esésével lesz, így a legfőbb cél a sávszélesség kímélése. Tile-based deferred acceleration egy DirectCompute 5.0-ban írt algoritmus, mely kihasználja a Local Data Share előnyeit, ami nagymértékben csökkenti a sávszélességigényt. Ezzel lényegében megszerzed a szükséges pixelenkénti információt anélkül, hogy kicsinálnád a kártya memóriaalrendszerét. Az MSAA azonban problémás továbbra is, és összességében ez a megoldás jár a legtöbb memóriahasználattal, még ha a belső adatmegosztás a sávszélességet aránylag kíméli is.
  Eddig egyébként szvsz a Partial Defered Lightning volt az arany középút. Ez persze az én véleményem. Láttunk már Full Defered Lightningot is a STALKER: CoP-ban, és hogy a Partial Defered Lightningra is legyen példa ott a Crysis 2 (persze csak egy-egy példát hoztam fel ... van több is). A Tile-based deferred acceleration viszont erősen megkérdőjelezi mindkettőt, mert a memória használatát leszámítva eléggé kímélő, de a minősége elképesztő lásd BF3. Szvsz most ez a top megoldás, és nem is nehéz vele bánni. Ezt a gyártók is látják, és reagálnak rá sok VRAM-mal, mert az igények erre mutatnak. A másik követelménye, hogy csak DX11-es kódban működik, de manapság ez már nem gond. Persze az AA-val állandóan trükközni kell, így előtérbe kell hozni a post-process megoldásokat.
  A BF3-at egyébként Full HD-ben AA nélkül 1 GB-ra tervezték. 1,5 GB-ot eszik Full HD-ben 4xAA-val. Ha Full HD fölé mész (pl.: 2560x1600), akkor csak a deferred render képkocka információi, a frame buffer, és a back buffer 1 GB, és akkor még semmi más nincs a VRAM-ban. Ehhez még kell 1 GB. Ha Eyefinityzel, akkor 3 GB a minimum, mert 2+ GB-ot eszik a képkockaadat 3x Full HD-ben. Látszik, hogy nem kíméli a VRAM-ot a gyorsítás, de sebességben nagyon jó.
  Szintén felhozható az új Serious Sam 3, ami Full HD-ben teljes AA-val megeszi a 2 GB-ot. Fölötte még a 3 GB is kevés lehet. Ez persze a méretes textúrák miatt ilyen zabagép, na meg a streaming algoritmus sem valami agresszív.
  Aztán gondolni kell az új Radeonoknál a PRT eljárásra, ami egyfajta cache-ként használja majd a VRAM-ot. Itt minél több memória van, annál jobb. Persze a PRT a jövő zenéje, mert még csak OpenGL-re működik, így a DX-es implementálással meg kell várni a Win 8-at, viszont valós időben alkalmazható vele a Disney Ptex textúra, ami nagyon megkönnyítheti a fejlesztők munkáját, hiszen végre nem kell UV mappozni az eltérő részletességű modellekre.

  (#203) Callisto: Nem, de a GDDR5 ára is szépen esik a DDR3-mal egyetemben. Tekintve az aktuális fejlesztések irányát, megéri a többletmemória. Ha mást nem, akkor a Tile-based deferred accelerationt mindenképpen érdemes lereagálni.

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