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

• Loha veterán

  #627

  #620 Abu85

  2013-04-08 18:25:02

  Új Válasz

  Ú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

  

  Loha

  veterán

  #620 Abu85

  #620 Abu85

  Ha lehetőségünk lesz az FCAT-hoz szerezni hardvereket, akkor megfontoljuk a lehetőséget, de akkor előre beszéljük meg, hogy nem lesz abból sírás, hogy ha a kevés játék miatt az új programokkal a Radeon sebességelőnye túlzottan nagy lesz összesítésben.
  A BF3 az mindegy. Az egy kommunikációs hiba a DICE és az NV között. Nem az ilyenek miatt aggódom, hanem a Tomb Raider eredményi miatt, ami az új patch mellett nagyon nem a GeForce-oknak kedvez. De jön még idén ehhez hasonló játék.

  (#608) Loha: Ebben nem látom, hogy hol írják, hogy a T_presenttől mér. Azt írják le, hogy a képkockákat color barozza. Ezt írom én is. Ez a display idő.
  A Far Cry 3 beférne, ha méltóztatnának a fejlesztők javítani a HDAO-t az NV kártyákon. Az a baj, hogy simán beraknám a játékot, de a HDAO problémás megjelenítése és lassú számítása nem az NV hibája, hanem a játéké. Sportszerűtlen lenne ezért az NV-t lehúzni, hogy nem tudja hibátlanul futtatni a játékot.

  (#618) TTomax: A GCN az attól még GPU, hogy a CU-k elnagyolt logikai felépítése hasonlít egy CPU-maghoz. A feldolgozási elvet kell nézni. A CPU-k magjai LCU-k, azaz késleltetésre optimalizált magok, pár szállal és nagy gyorsítótárakkal. A GPU-k magjai TCU-k, vagyis adatpárhuzamos végrehajtásra optimalizált magok, baromi sok párhuzamosan futó szállal és relatíve kis gyorsítótárakkal. A GCN az utóbbi csoportba tartozik, csak a mai viszonyokhoz képest fel van okosítva a rendszer, hogy amitől egy hagyományos GPU kikészül, attól ez már ne készüljön ki (például feltételes elágazásokkal és soros for ciklusokkal tarkított kód). Gyakorlatilag egy működő Larrabee, az AMD lemásolta az Intel ötletét.

  (#616) TTomax: Nem VRAM limites a Bioshock Infinite. Az UE3 motor nagyon finoman bánik a VRAM-mal. A gond ott kezdődik, hogy a motor streaming rendszere széles skálán paraméterezhető. Na most az amit eredetileg beállítottak arra van szabva, hogy a Radeonokon jól működjön, az NV pedig ezt használja, és a GeForce-okon nem működik jól. Ezt nagyon egyszerűen lehet módosítani az engine-höz tartozó ini fájlokban, és rögtön jól megy GeForce-on is.

  FRAPS méri, hogy hány képkockát küldött tovább az engine, az overlay tool meg ráteszi a csíkokat. A videóból, majd a kielemzéséből kijövő grafikon, ha megegyezik a FRAPS által készítettel, akkor az engine és a monitor közti késleltetés nagyjából állandó. Ha nem egyezik meg mint CF esetén, akkor az engine és a monitor között vmi nem úgy történik a VGA driverben vagy magában a VGA-ban ahogy kéne, mert nem olyan ütemben érkeznek a képkockák a monitorra, ahogy a játék motorja küldi őket. 1db AMD VGA eredményeiből tudjuk, hogy átlag mennyi idő feldolgozni egy képkockát, 2db ugyan ilyen VGA esetén ennek közel a felére kellene esnie ahogy SLI esetében, de nem ez történik, hanem szinte nulla idő alatt végez egy képkockával a CF rendszer, de a következőt annyi idő megcsinálnia, mint 1db VGA-nak, és mivel az esetek többségében a szinte nulla idő alatt a monitorra érkező előtti képkockából nem látunk semmit, azért a játékos számára sok esetben olyan késleltetéssel érkeznek a látható képkockák, mintha csak egy VGA lenne a gépében, tehát számára a CF rendszer vizuálisan az esetek egy részében nem nyújt többet 1db VGA-nál.

  FarCry 3-nál nyugodtan teszteljetek SSAO-val és akkor nem lesz az a probléma, hogy egyik félnek a HBAO másiknak meg a HDAO fekszik jobban, vagy teljesen ki is lehet kapcsolni az AO-t, úgy is inkább csak ront a látványon.

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