-
GAMEPOD.hu
nVidia GeForce GTX 670 / 680 / 760 / 770 (GK104) téma összefoglaló
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Én a techreport alapján néztem. A BF3 egész jó. Amelyik VGA-nak van elég memóriája memóriája annál nincs kiugrás. Max Payne 3 és Skyrim dettó. A Dirt Showdownt ugye elmondtam. Ott a forward+ render nem fekszik a régi elvek szerint megépített GPU-knak. Az Batman AC esetében elég nagy a szórás, mert el van baszva a DX11 kód. Ez program oldali gond, azért érint minden terméket. Crysis 2-t gondolom nem kell bemutatni.
Senki sem élvez előnyt. A legtöbb tüske a rossz optimalizálás eredménye. A hardver oldalán a kevés memória, illetve a compute játékoknál a bonyolult kód okozhat ilyet. Az előbbi több memóriával megoldható, míg az utóbbi az ilyen marad.
8 RT-t használ a BF3.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
SzlobiG
#7726
üzenetére
Sebességben igen. A Hyper-Threading kikapcsolása az apró akadásoktól szabadít meg. De kérdés, hogy ki mennyire érzékeny ezekre. Ennek a problémának minden Frostbite 2 motort használó játéknál ez a megoldása. Majd lesz a motornak egy új verziója. Az már nem lesz haklis a Hyper-Threadingre. Persze vissza már nem patch-elik a programokat.
Szerk.: Ez a Frostbite 2, ami van a Most Wanted alatt, azon belül is az a verzió, amit a MoH: Warfighter használ. A Hyper-Threading problémáját folyamatosan próbálják javítani. Már nem olyan feltűnő, mint BF3 alatt volt, azt is patchelték folyamatosan. A fő gondot, ami okozza azt a motor első komolyabb frissítésénél tüntetik el.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
SzlobiG
#7731
üzenetére
Valóban. Azért az EA szépen agyonreklámozta, hogy FB2. Akkor a Hyper-Threading nem okozhat neki gondot.
(#7730) H.Ezredes: A 12.11 béta1 verzióját megnéztem anno. Az valóban +15-20 fps BF3-ban. Azóta nem volt időm ilyenekre, így a többi bétáról és a GeForce bétáról nem tudok nyilatkozni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
SzlobiG
#7738
üzenetére
Közelében nincs a mosottsága.
Nézd meg ezeket a képeket:
nincsAA - FXAA (3.11) - MLAA2.0Az FXAA az a RadeonPro programból van berakva az alkalmazásra. A noAA képek a box gombok ne zavarjanak meg. Xbox gamepad mellett átvált a rendszer PC-n is.
A TXAA egy másfajta AA. Más a koncepciója. Az persze a visszajelzések alapján nem tűnik logikus döntésnek, hogy az FXAA további fejlesztését leállították.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
SzlobiG
#7745
üzenetére
A BO2-re is ugyanaz az algoritmus megy rá, mint ezekre a képekre. Azt nem tudom, hogy az NV beépített FXAA-ja milyen paraméterekkel dolgozik. Lehet, hogy rosszabbal, mint a RadeonPro beépített megoldása, mert az egész konfigurálható, így kérdés, hogy az implementációt ki hogyan konfigurálja. Az viszont biztos, hogy az MLAA2.0 annyira felfejlődött, hogy a driverből is használható. Közelében nincs a mosott képnek. Nagy fejlesztés, hogy a 2.0-s algoritmus subpixel pozícióra tolja a mintákat.
A BO2 csak FXAA-t használ post-process AA-ra. Az FXAA-nak van egy alapalgoritmusa, ami szerintem már minden játékban a 3.11, de azon kívül a működése paraméterezhető. Az NV használ egy paraméterezést a driverben, a RadeonPro is használ egyet (valószínű, hogy a 3Dcenter fórumán fejlesztett injectFXAA sharpen verzióját), míg a játékok is használ egy saját, paraméterezett megoldást. Ezek között még az alapalgoritmus egyezése esetén is van különbség. És itt nem arra gondolok, hogy a játékokban a HUD-ot a szűrés kihagyja.
----
A BO2 sebességéhez ... Az Activision koncepciója mindig az volt a motorok tervezésénél, hogy a lehető legtöbb gépen menjen 60 fps-sel. Szóval várható volt, hogy ez most sem változik meg, így a GPU-k kihasználtsága eléggé alacsony, de legalább szinten mindenen fut a program. A DX11 is csak a gyorsítás miatt van benne. Semmi extra effekt, ami DX10/10.1 alatt nem érhető el. Lehet azt mondani, hogy a grafikája nem hű a 2012-es normákhoz, de számításba kell venni, hogy jóval kisebb a gépigénye, mint a konkurens háborús játékoknak, mint a MOH Warfighter, vagy a BF3. Ennek megfelelően alakul a grafika is. Az egész motor nagyon egyszerű dolgokból épül fel, semmi bonyolultabb shader, hogy ne feküdje meg a gyomrát a régi kártyáknak. A megvilágítási modell is nagyon maradi, ami annak tudtában meglepő, hogy a Treyarch motorfejlesztése deferred renderre tért át az IW forward render motorjáról. Ha nem tudom, hogy a motor deferred render, akkor azt mondom rá ránézésből, hogy ez bizony forward. Valszeg kevés pontfényforrást használnak, ami sejtésem szerint a teljesítmény szinten tartása érdekében történik így.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A 3DCenter.org fórumozói fejlesztik ezeket. [link] Ezen belül fogalmam sincs. Én is csak a RadeonPro programmal néztem meg, de csak kíváncsiságból, mert az MLAA2.0 így is jobb, így nincs szükségem ezekre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Az MSAA szerencsére itt annyira nem zabagép (bár nincs is ingyen
). A global illumination, ami terheli a kártyákat. Ugyanazt a megoldást használja, amit a CryEngine 3 (Light Propagation Volumes), csak sokkal több fényforrással, és compute shaderben van írva az egész. Kepleren én a GI kikapcsolását fontolnám meg, de ha nem kell 50-60 fps, akkor az MSAA nullázása is megoldás. Esetleg opció a Depth of Field minőségének csökkentése. Az is compute shaderben van írva.(#7885) gbors: A Glacier 2 nem ugyanúgy használja az MSAA-t, mint a Battlefield 3. Szimplán trükköznek vele. Ezért nem öli meg teljesen a teljesítményt. Persze számít, de messze nem annyira, mint a BF3-ban, vagy más Frostbite 2-vel dolgozó játéknál. Hasonló a Hitman Absolution megvalósítása, mint amit a Stalker: CoP használt. Ez nem meglepő, ahhoz is az AMD adta a kódot.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
-
Abu85
HÁZIGAZDA
A HDAO az természetes, hogy eszi az fps-t. Az AO megvalósítások közül ez az, ami compute shaderes (itt fekszik le a Kepler), és ez az egyetlen a programban, ami a natív felbontással számol. A másik két megoldás nem használ compute shadert (ezért jobb Kepleren ennyivel), és a felbontás felével számolnak. Ha a HDAO is a felbontás felével számolna, akkor az lenne a leggyorsabb, de azt a minőségre gyúrták ki. Amúgy ez így nem rossz megoldás. Mindenki azt választja, amelyiket akarja. Ilyen a Stalkerben láttunk, ott is felkínáltak négy AO opciót, és válaszd amelyik tetszik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
viktor82
#8129
üzenetére
A Kepler architektúra kapcsolata a compute shaderekkel régóta ismert. A DX11-es architektúrák közül a Kepler LDS sebessége a leggyengébb, és a kontextusváltás is nagyon lassú rajta. A Fermihez képest egyértelmű visszalépés. Ez magyarázza, hogy a HDAO, ami alapvetően minden DX11-es architektúrán gyorsabb a HBAO-nál, Kepleren már nem gyorsabb. Az, hogy ezt leírom nem szidás. Megmondtam, hogy miért alakul, így Kepleren a sebesség. Használjatok HBAO-t.
(#8133) Tirexi: Igazából a motor működéséből kiindulva nem egy AFR barát megoldás. A DiRT Showdown sem az. Valószínű, hogy nagyon speciális rutinok kellenek, hogy egyáltalán használhatóan működjön a CF és az SLI.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
viktor82
#8135
üzenetére
Sosem értettem a fanatizmust, amikor nyilvánvaló dolgokat nem lehet elfogadni.
A driverkérdést a másik topikban kitárgyaltuk. Maradjunk annyiban, hogy nem a Catalyst miatt kellett kivenni egy játékot a tesztcsomagunkból. Hidd el azt is megtehettük volna, hogy szarunk rá, hogy a GeForce drivernek problémája van a programmal, és akkor harmadannyi sebességet ért volna el, mint a vele azonos árú Radeon. Csak sportszerűtlen lett volna, mert nem reprezentálta volna a hardver képességét a szoftveres probléma miatt.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
viktor82
#8137
üzenetére
Ahhoz képest én tényekre építem a mondandóim, amiket le lehet ellenőrizni. Ha ez fanatizmus, akkor durva világban élünk. Te csak mondtál valamit, amit semmivel nem támasztottál alá. Lóg a levegőben, és másnak a szemét is szúrja, hiszen láthatod, hogy neked támadtak a másik topikban.
Nekem nagyon mindegy, hogy mit veszel, és az is, hogy mit tartasz jobbnak.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
RockHaRD
#8172
üzenetére
Gyakorlatilag a HBAO és a HDAO is ugyanarra való funkcionálisan csak más az algoritmus. Egy effektet többféle módon meg lehet oldani, és maga az SSAO effekt pont olyan, amire több eltérő megoldás létezik. A HDAO ezek közül a legmodernebb, és ez adja a legjobb szimulált hatást. Gyakorlatilag egy tradicionális SSAO, de compute shaderben van írva, ezért sokkal gyorsabban számol (a DX9-es SSAO-hoz képest 7x gyorsabban). Ez adja meg azt a lehetőséget, hogy a natív felbontással legyen az effekt megoldva, és a rengeteg mintával finom lehet a megvalósítás. Gyakorlatilag ebből a szempontból a HDAO semmi radikálisat nem alkot, abból nyeri a minőséget, hogy nagyon sok minta áll rendelkezésre és sokat számol. A HD is erre utal.
A HBAO egy igen speciális megoldása a problémának. Ez tulajdonképpen kiegészíti az SSAO-t azzal, hogy minden egyes mintához egy horizont szöget számol, amelynek szinuszából kivonja a tangensvektor által bezárt szög szinuszát. Ezzel kevesebb mintavétel szükséges ahhoz, hogy hozza azt az eredményt, amit egy SSAO. Hátránya, hogy többet kell számolni, de ma már ez inkább előnyös egy új generációs GPU-nál.Összegezve az eljárásokat, akkor azt mondhatjuk, hogy ha a sebességet nézzük, akkor azonos paraméterezés mellett a HDAO messze a leggyorsabb megoldás, viszont a fejlesztők általánosan másképp paraméterezik az algoritmusokat. Gyakorlatilag általánosan jellemző, hogy ha több screen space AO megoldást raknak egy játékba, akkor a tradicionális SSAO és a HBAO a felbontás felével dolgozik, míg a HDAO a natív felbontással. Ennek megfelelően a valós implementációt figyelembe véve a HBAO és az SSAO a két leggyorsabb megoldás, míg a HDAO valamivel lassabb. Viszont HDAO négyszer több adattal dolgozik, vagyis minőségben ez adja a legjobb szimulált hatást.
A color sample mértéke alapján az említett AA módok közül a 16xCSAA a leggyengébb. Ennél jobb a 8xMSAA, és ennél jobb a 16xQCSAA. Nagyjából ez a sorrend is a minőségben.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#8204
Abu85
HÁZIGAZDA
gainwardgs
#8202
Abu85
HÁZIGAZDA
válasz
gainwardgs
#8202
üzenetére
Játszhatsz egy kicsit a max buffered frames beállítással. Ha kellő VRAM áll rendelkezésre, akkor az is gyorsíthat. Persze nem biztos, de próba szerencse.
(#8203) torma1981: Persze. Ezért adták ki. Kicserélték számos effekt algoritmusát. Mondtam, hogy a review kód lényegtelen, mert lesz egy day0 patch.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
viktor82
#8221
üzenetére
8xMSAA-val az. De örülnék, hogy ha linkelnéd, hogy hol mondtam, hogy GTX 680-on játszhatatlan lesz.
Amit az FC3-mal kapcsolatban mondtam, hogy lesz egy day0 patch, ami sokat változtat a kódon. Ez így történt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
SzlobiG
#8256
üzenetére
Ambient Lighting csak medium, Water csak high, post FX szintén csak very high ... na meg SSAO. Gyakorlatilag ezekkel sikerült kikapcsolni az összes compute shadert a játékban. Ki tudja miért.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
RockHaRD
#8261
üzenetére
Változó. Az 1 az biztos, hogy jó mindegyik VGA-nak, de ha több VRAM van a kártyán, akkor érdemes kipróbálni egy nagyobb számot. Viszont ennek a pozitív eredménye nem garantált. Ez próba szerencse dolog.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
RockHaRD
#8264
üzenetére
Az 1frame az a dual buffer, míg a 2frames az a triple buffer. Nem értem, hogy miért nem így hívják őket, de ez a nevük. Ha sok VRAM-od van, akkor a triple buffer az ajánlott. Ez is olyan dolog, amit érdemes kipróbálni, mert nem általános, hogy melyik a jobb.
2 GB VRAM-mal lehet, hogy az 1 a kedvezőbb.
Az az átlátszó textúrákon csinálja az élsimítást. TrSSAA gyakorlatilag, csak nem így jelzik.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De miért kell elfelejteni a november 16-án kiadott Catalyst drivert, ami az AMD FC3-ra optimalizált drivere? Az nem számít, mert hamarabb jött, mint az NV drivere? Már megint ez az egyoldalúság. Miért adjon ki az AMD drivert két nappal a játék megjelenése előtt, amikor megtette két héttel előtte? Komolyan ez az amit felrovunk?
(#8324) gbors: Például az 1.01-es patch teljesen eltávolítja a játékból a DX11 multi-threading kódot. Ez durva változás, mert a renderbe is beavatkozást igényel. Illetve az utolsó pillanatban minden compute shader kódot kicseréltek egy jobban optimalizáltra. Ez is szintén jelentős eltérés.
Az 1.01-es kód november 12 óta elérhető a partnereknek (jelen esetben csak az AMD). A 310.64-et 20-án véglegesítették. 8 nap alatt nem lehet kielemezni és profilt írni egy alapjaiban megváltozott patchez. Főleg nem így, hogy az NV meg sem kapta, mert nem ők kezdeményezték a változtatásokat.CF működik a 12.11 beta 8 driverrel és a legújabb CAP-pel. A gondokat az okozza mindkét oldalon, hogy a profilt az 1.00-s kódhoz írták. A mostani driverek is ehhez a kódhoz vannak írva mindkét oldalon. Igazából az egész gondot az okozza, hogy az Ubi a fejlesztés végén hagyta ott a TWIMTBP programot és utólag átálltak a Gaming Evolvedre. Az 1.01-es patch lényegében az a kód, ami az optimalizált grafikai elemeket tartalmazza. Fentebb leírtam, hogy mi az ahol komoly változás történt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mindkét oldalon vannak problémák. Mégis hogyan várod el, hogy 1.00-ra optimalizált driverek megfelelően működjenek, amikor 1.01-es kód van. kivették a teljes multi-thread rendert, és ez konkrétan a kód átírásával jár.
Tisztázzuk alapból sem a CF sem pedig az SLI nem tökéletes. Ezt a problémát szintén az okozza, hogy nincs 1.01-es kódhoz optimalizált driver. Konyhai hackre pedig miért csak az NV-nél lenne lehetőség? Ez is egyoldalúság.
Most rányomsz egy debuggert, és elemzed a kód működését az nem kevés idő. Minden munka, amit eddig csináltak a cégek az 1.00-s patch-re az gyakorlatilag lényegtelen volt. Maximum tapasztalatot ad, hogy ennél a játéknál, mely részekre érdemes figyelni. Nagyjából 30-40 nap alatt lehet egy kódra megfelelő optimalizálást írni. Látszatra azért dolgoznak a drivert írók annyira gyorsan, mert jóval a kiadás előtt megkapják a kód változásait. Az FC3-nál lényegében másfél hónappal a végleges kód lezárása előtt még olyan dolgokról ment a vita, hogy maradjon a motor úgy ahogy van, vagy legyen megváltoztatva. Az AMD vállalta, hogy másfél hónapon belül megoldják az Ubi gondját, de ez a driverekre kellemetlen hatással lesz, mert kvázi a kiadásra lesz kész a módosított kód. Az Ubi erre rábólintott és ezért van itt az 1.01-es patch. Még az is lehet, hogy jön új patch.
Az 1.01-re lesznek driverek, valószínűnek tartom, hogy tovább fog a sebesség gyorsulni, és az SLI/CF-re sem kell konyhai hack, hogy skálázódjon. Az kérdés, hogy az erőviszony hogyan alakul. Egyelőre a day0 változtatásokat kellene lereagálni.(#8430) Carrot007: Ez valóban buta döntés volt, de ne feledd, hogy ez a játék szeptemberben még TWIMTBP cím volt, az NV még reklámozta is a sajtónak. Aztán az Ubisoft az AMD-hez menekült. Így lett az FC3 Gaming Evolved. Ez hozta az 1.01-es patch-et, mert kevés volt az idő a végleges kódba belerakni azokat az optimalizálásokat, amiket az Ubi kért. Itt az volt a hiba, hogy az Ubi megpróbálta egyedül megoldani a compute shadereket. Már nyáron az AMD segítségét kellett volna kérni, mert az NV nem fog compute shadert írni egy játékba, amíg a Kepler ezek futtatása szempontjából a valaha készült leggyengébb architektúra. Ez üzletileg érdekellentét. Az meg hülyeség, hogy az Ubi maga áll neki ezeknek a kódoknak. Túl időigényes ezeket megírni, még a Windows 8 új tracer rendszerével is. Ráadásul tapasztalat is alig van ebből a szempontból a játékfejlesztők oldalán. Eddig mindenki az AMD és az NVIDIA kódjaira támaszkodott.
(#8432) SzlobiG: Ha jobban akarod, hogy menjen ugyanolyan hack kell neki, mint az SLI-nek. De mint mondtam egyetlen driver sem készült az 1.01-es patch változásaira.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
1. Persze, hogy felfoghatatlan, amikor se bizonyítani, sem pedig definiálni nem tudod. A tesztekben problémáról nem írnak egyik oldalon sem, de múltkor már mondtam, hogy nem a Catalyst, hanem pont a GeForce driver miatt került ki egy játék a tesztcsomagunkból, illetve linkelték mások neked ezt is: [link] És ezek alapján ki mered egyértelműen jelenteni, hogy a GeForce driver jobb, de mindezt semmilyen Catalystes tapasztalatra nem alapozod, illetve figyelmen kívül hagyod a teszteket. Szerintem egyszerűbb abban megegyezni, amit egy ideje mondok. Egyik oldalon sem más a helyzet a terméktámogatás szempontjából.
2. A CF is működik úgy ahogy az SLI, és a jobb hatásfokhoz a CF-be is bele kell túrni. De már leírtam, hogy az 1.01-es patch-hez senki sem írt még profilt. Azt előbb ki kell elemezni.
3. Soha sem mondtam, hogy az AMD erősebb lesz Far Cry 3 alatt, de azt sem, hogy nem. Azt mondtam, hogy az FC3 egy Gaming Evolved cím miután szakított az Ubi az NV-vel. Nyilván az 1.01-es patch-ben a compute shader effekteket nem véletlenül cserélték le. A számok egyelőre semmit sem mutatnak, mert az egyetlen teszt, ahol az FC3-at az 1.01-es patch-csel tesztelték az a Guru 3D tesztje és ott sikerült kikapcsolni az összes compute shader effektet. Nyilván ez ma alapvető kérdés a tesztelőknél, mert az egyik oldalról azt hallják, hogy a compute shader "maga az ördög", míg a másik oldalról azt, hogy nagyon sokat lehet vele gyorsítani. Szerintem kitalálható, hogy melyik oldal melyik álláspontot foglalja el. A tesztelő is belátása szerint dönt, hogy kinek hisz.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
SzlobiG
#8445
üzenetére
Én is linkeltem egy topikot. Mit számít ez? A szoftverben van hiba, de egyik sem jobb a másiknál. Mindig annak a szoftvernek a hibája számít, amire éppen van hardvered. Ellenben a tesztekben nincs semmilyen, hangsúlyozom semmilyen adat arról, hogy rosszabb lenne az egyik cég támogatása. De ha a tapasztalatainkra építünk, akkor például nem az AMD drivere miatt vettük ki a tesztekből a Shogun 2-t, hanem pont a GeForce driver volt ennek az oka.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
És miért nem írnak ezekről a tapasztalatokról a tesztek? Ez egy óriási kérdés. Mert ott bizony nem írnak arról, amiről te.
A DX10.1 nagyon hasznos volt. Voltak rá játékok, ahol vagy szebb volt a képminőség, vagy gyorsabb volt a DX10.1-es kód a DX10-eshez képest. Erről anno írtunk is. Számos olyan DX11-es játék van, ami MSAA-t csak DX10.1 alatt engedélyez, de DX10 mellett már nem, és ez vonatkozik más effektekre is.
A DX11.1 működését nem sokan értik, de erről írok egy részletesebb anyagot. Ellenben csak egy példát mondok. Biztos láttál már a játékokban shadow mapot. Az árnyékok recések és enyhén zizegnek. Ez egy ismert probléma, ami eltüntethető, de az aktuális API nem olyan rugalmas, hogy ezt drasztikus sebességcsökkenés nélkül megtedd vele. A DX11.1 egyik újítása képes arra, hogy ez a gong eltűnjön.
Ezt még az Intel vetette fel, amikor még úgy volt, hogy a Larrabee-ből lesz gaming termék is. [link]
Azok fícsőrők, amiket anno az Intel bemutatott, mind megvalósíthatók a DX11.1-gyel. Nyilván az egyik cégnek érdeke, hogy azt hidd, hogy ez nem fontos, de ezekbe a funkciókba beleegyezett mindenki, hiszen elfogadták a specifikációkat. Nem véletlenül lettek ezek kifejlesztve. A következő generációban lesz az NV-nek is a DX11.1-es hardvere, és akkor hirtelen már fontos újításokról fognak ők is beszélni. Ezt tették a DX10.1-nél is. Ahogy lett rá hardverük, azonnal fontossá vált az API. Persze így működik az üzlet. Amíg nincs rá hardver, addig az újítások nem érnek semmit, aztán hirtelen rájönnek, hogy mégis fontos dolgok ezek. Most is mi történt? Elmondták, hogy a Kepler minden gaming fícsőrt támogat. Erre a dev fórumokon ment azonnal a kérdés, hogy, ha ez igaz, akkor az UAV miért nincs támogatva az összes shader stage-en? Erre még nem jött válasz. De nyilván érthető miért van csend. Van egy kevésbé hozzáértő réteg, és van akinek nem lehet badarságokat beszélni, mert az UAV az összes shader fázison baromira gaming fícsőr.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Kinek? Mit? A teszt nem árul terméket.
Ráadásul baromira mindegy, hogy ki lesz a győztes. Amúgy még az NV sem ír erről a blogjában. Fel sem hívják a figyelmünket rá, hogy ilyen létezik. Amelyik teszt tesztel frame time-ot, ott pedig konkrétan megcáfolják az állításod.Kár, hogy nem olvastad el. Nyilván így nehezen fogod megérteni, hogy miért frissítik ezeket a szerencsétlen API-kat új funkciókkal.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem mondtam ilyet, csak olyan problémák kivetítésére reflektáltam, amire még senki sem állt elő bizonyítékkal. Hihetetlenül furcsa, hogy a világon legalább száz média tesztel termékeket, és senki sem veszi észre ezeket a gondokat.
A DX9 a programozhatóság szempontjából elég jó API. Gyakorlatilag majdnem mindent meg lehet benne csinálni. A DX10-től az API a rugalmasság és a gyorsabb feldolgozás felé megy, vagyis az a cél, hogy amit DX9-ben megcsinálhatsz, azt DX1x-ben könnyebben és gyorsabban meg tudd oldani. A DX10 hozta a reformokkal a könnyítést, míg a DX11 a compute shaderrel a gyorsítást.
A usereknek nem muszáj váltani, hogy a DX11.1 előnyét te érezd. A fejlesztőknek kell váltani Windows 8-ra, hogy korszerűbb fejlesztőkörnyezethez és shader tracer interfészhez jussanak. A fejlesztő ezzel gyorsabban tud írni hatékonyabb kódot. Az futni fog Windows 7-en is. Sőt, még Vistán is.
Képzeld el, ha nem DX11-ben lenne írva a program. 5 fps-sel se menne.
Az MSAA az nehéz ügy. Nyilván mindenki látja, hogy nem ideális egy deferred render motorhoz, de azt is látja mindenki, hogy nincs valós alternatívája. Ebből a szempontból van értelme belerakni, max. kikapcsolod, ha nem kell. De szerintem az MSAA kora újra eljön, mivel ma már van olyan forward render megoldás, ami a deferred render előnyeit a hátrányok nélkül is felkínálja. Innentől kezdve az MSAA újra olyan lehet mint régen. Akár driverből is bekapcsolható lehet. A hardver fejlődése szempontjából is olyan irány érvényesül, hogy a compute tempó és hatékonyság gyorsabban nő, mint a memória-sávszélesség.
Az API-kban megvannak a korlátok. Ezek egyre nagyobb limitációt jelentenek. Már van arról pletyka, hogy a DX ugyan megy tovább, de jön mellé egy radikálisan új alapokra helyezett rendszer is. Ez hozhat majd áttörést. Viszont ehhez mindenkinek meg kell egyeznie egy közös IL használatáról a saját Il helyett.
A kockás fejek, a textúrák és az animáció inkább művészekre vonatkozó dolgok. Az API ezért nem hibáztatható. A fizika problémái a játékmenettel és a technikai korlátokkal kapcsolatosak. Egy teljesen rombolható terep nehézkes, mert az AI problémákba eshet vele, illetve a fizika egyes részei gyengén vagy jól párhuzamosíthatók. Ez hardverrel kapcsolatos probléma, mert ahhoz, hogy ezek a részek elkülöníthetők legyenek ki kell ütni a PCI Express késleltetését az integrálással.(#8457) TTomax: A 2D órajel és az idle fogyasztás az jó. Amit nem bír az a 3rd party progi. Ha fel van telepítve, akkor még tuning nélkül sem biztos, hogy a Catalyst Overdrive modulja töltődik be, és ha nem töltődik be, akkor nem szabványos a PowerTune paraméterezés. Nyilván ez a 2D-s villogás a tesztekben megint azért nem fordul elő, mert ott nincsenek működést befolyásoló programok. Eleve, amikor ezeket telepíted, akkor el kell fogadnod a feltételeket, abban benne van, hogy a telepítés után a termék gyártója nem felelős a termék stabilitásáért. Ez akkor is él, ha semmit sem tuningolsz rajta, mert változnak a paraméterezések.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egy ideje erre megyünk. Például ott van az a pletyka, hogy az Intel roadmapján már nem szerepel cserélhető processzor. A Broadwelltől az alaplappal együtt veszed. Nem tudod csak a procit kicserélni, mert rajta van az alaplapon.
A PC tradicionális értelemben, úgy ahogy te értelmezed meg fog szűnni. A platform válik a kulcstényezővé, és a hardvereket is így tervezik majd. A dedikált GPU még kérdéses, hogy megmarad-e. A gyártók terveiben szerepel, de már úgy, hogy az extra funkciók platformhoz lesznek kötve, vagyis az NV GPU-hoz érdemes lesz NV APU-t venni, és az AMD-hez AMD APU-t. A konkurensek mixelése nincs kizárva, de bizonyos funkcióktól elesel.Ha villog, akkor rossz a kártya. Ez garanciális.
A 120 Hz az nincs gyártóhoz kötve.
Az AMD minden olyan 120 Hz-es sztereó 3D-s kijelzőt támogat, aminek HDMI 1.4a bemenete van, és az integrált emitter nem zárolt. Az NV-nél pont fordítva működik. Minden olyan kijelző támogatott, ahol az integrált emitter zárolt. A zárolást úgy lehet a legkönnyebben megnézni, hogy van-e a kijelzőn 3D Vision matrica vagy minősítés. Ha van, akkor zárolt, így nem megy AMD-n, ha nincs, akkor nem zárolt így megy AMD-n, de nem megy az NV 3D Vision.
A passzív 3D esetében nincs ilyen kikötés. Az minden szempontból kompatibilis. Ezért terjed ennyire.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
1. Ppanaszkodók mindkét oldalon vannak szép számmal. A tesztelők egy része nem tesztel régi játékokkal. Például mi arra törekszünk, hogy mindig a legújabb címek kerüljenek a tesztcsomagba.
2. Nem nekem kell felhívni arra a figyelmet, hogy telepítsék a 12.11 beta 8-at és a legújabb CAP-ot. Ez úgy gondolom, hogy logikus.
3. A Far Cry 3-at sosem hoztam fel erre, sőt, egészen pontosan leírtam korábban, hogy az alkalmazott GI megoldás nem olyan, amilyet ma használnak a játékok, hanem DX10/10.1 alatt is működőképes, így nem is használ compute shadert. Amiket felhoztam az a DiRT Showdown, a Ghost Recon: Future Soldier, a Sniper Elite V2, a Sleeping Dogs és a Hitman Absolution. De nyilván a Far Cry 3 abból a szempontból talány, hogy végül jött egy patch, ez okozhat meglepit, de ahhoz először mindkét cégnek rá kell néznie a megváltozott kódra. Na meg az is kérdés, hogy minden változást sikerült-e belerakni az 1.01-es patch-be.
Amit le szoktam írni, hogy a compute-igényes játékokban a Keplernek nincs esélye az azonos árú GCN-es Radeonnal. Erre a tesztek bizonyítékként szolgálnak a fenti játékokban. A compute terhelés persze eltérő lehet. A mi tesztjeinkben például pont azért olyan erős a GCN, mert beraktuk az új játékokat. Ha ezt nem tettük volna, akkor nem lenne ennyire erős.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ha az FC3-mal akarsz játszani, akkor ez most elengedhetetlen mindkét oldalon, mivel a WHQL driverek októberiek.
Ez a játék eredetileg TWIMTBP volt. Szeptemberben még az NV reklámozta, csak az Ubi az AMD-hez ment segítségért, mert valamin talán nem értettek egyet az NV-vel. A day0 patch az AMD által fejlesztett módosításokat tartalmazza a renderre részben, vagy esetleg egészében. Mivel gyakorlatilag volt kemény egy hónapjuk megcsinálni, amit kértek, így nagyon szűkös időkerettel dolgoztak. Jellemzően fél évvel a játék megjelenése előtt már elkezdik a driverrel a munkát. Ezért nem szokás drasztikus változásokat eszközölni a végleges kódban. Például olyat, mint az FC3 1.01-es javítása. Persze az ilyen változtatásoknak mindig megvan az oka.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ami az NV-t is. A WHQL aláírás pénzbe kerül, így a béta drivereket nem küldik el tesztre, amíg teljesen ki nem tesztelték maguk. Eleve az aláírás három hét. Tehát a tervezett kiadás előtt négy héttel késznek kell lennie a drivernek. Valószínű egyébként, hogy a béta 7-et vagy a 8-at elküldték WHQL-re. Az NV-nél nem tudom, hogy melyiket küldik, de ha decemberben még ki akarnak adni WHQL drivert, akkor a 310.64-et mindenképpen el kell küldeni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#8475
üzenetére
Amelyik teszt így nézi az fos. Szerencsére ma már nagyon kevesen dolgoznak így.
Van olyan teszt is, ami dropokat mér. Az állításoknak teljesen ellentmondanak az eredmények.Csak, hogy az AMD-nek van FC3-ra optimalizált drivere, amit november 16-án adtak ki. Ez az amit itt elfelejt mindenki. A Catalyst már 16-án kész volt az FC3 futtatására. [link] - benne is van ez: Includes single GPU performance updates for Far Cry 3
Az 1.01-es patch-hez pedig még senkinek sincs drivere.
Régebbi driverrel bárki játszhatja gond nélkül. Nekem 12.8-assal is fut, mert most ez van fent, mivel újra akarom túrni az OS-t valamikor, csak még nem vettem rá magam. Az első Far Cry 3 profil a Catalystbe valamikor tavasszal került be.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
[link] - láthatod, hogy itt szimplán a proci (Hyper-Threading) okoz akadásokat, szóval ezek a dolgok addig nem érnek semmit, amíg a hardver és a szoftverkörnyezet a két kártya esetében nem ugyanaz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem javították még ki teljesen, mert ahhoz nagyon bele kell túrni a kódba. Csináltak rá egy workaroundot, ami négymagos prociknál már jól működik, de a javítás közel sem teljes, így kétmagossal a helyzet változatlan. A videóval viszont arra akarok rávilágítani, hogy az akadásokat a rendszer egyéb része is okozhatja. Amire jó példa a Hyper-Threading ki- és bekapcsolása. De nem csak ez okozhat ilyet.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Carrot007
#8490
üzenetére
A HT bug általános. Van rá egy patch, ami a négymagos prociknál lényegében megoldotta. A kétmagosokkal viszont még továbbra is vannak akadások. A patch egy nagyon egyszerű workaround. Annyit tesz, hogy az Intel processzorokon a szálakhoz rendelt erőforrásokat másképp kezeli. Ez négy magnál elég, mert van elég erőforrás (picit csökken azért a teljesítmény, de nem vészes). Két magnál már kevés. A teljes javítást a 2.1-es Frostbite 2 motor kapta meg, ami a MoH Warfighter alá került.
(#8486) oliba: A DX10/10.1/11 már jó nekünk és nem jó lesz. Ha nem lenne DX11, akkor ugyanazt a grafikát, amit látsz egy DX11-es játékban a sebesség töredékével hozhatnád DX9 alatt. Ha ez nem jó, akkor nem tudom, hogy mi az ami előny egy új API-nál. Az, hogy nem csinálják meg a bonyolult effekteket DX9-ben pedig teljesen logikus. Minek tegyék meg, amikor nem lesz hardver, ami futtatni tudja őket. A lassulást innen érzed, mert az effekt csak DX11-ben van megírva. DX9-ben ki sem számolja. Így persze, hogy gyorsabb a DX9-es render.
A grafika minősége az nem csak az API-tól függ, hanem a művészi munkától. Ellenben ennél is limitálóbb hatású a pénz. Erről egyre többet beszélnek a fejlesztők, hogy jönnek a kétszer erősebb hardvereke, de grafika minősége nem nő a kétszeresére. Ez abból ered, hogy attól, hogy a hardverek erősebbek még a kiadó nem ad sokszor annyi büdzsét a tartalomkreálásra.
Ez most a legnagyobb téma a fejlesztőknél, hogy egyszerűbbé kell tenni a tartalomkreálást, mert a rendelkezésre álló pénzt hatékonyabban kell felhasználni. Erre jobb fejlesztőeszközöket használnak, illetve előkerültek az olyan dolgok, mint a ptex, a megatextúrázás illetve a procedurálisan generált tartalom lehetősége, vagy a tesszellálás vector displacement mappal. A lehetséges újítások (ptex, VDM) egy részére már van demó is. [link][ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
SzlobiG
#8493
üzenetére
Mint írtam nem csak ez okozhat ilyet. A szoftverkörnyezet is számít. Annyi a biztos, hogy olyan dolgokról, amikről beszámoltok egyetlen tesztben sem olvasni. Sőt, az ellentettjét támasztják alá a mérések.
Amire jellemzően érzékenyek a driverek, hogyha pucolod őket, vagy egyes programok felülírják a működést stb. Valószínű, hogy ez a titok nyitja is. A tesztekben nem pucolnak, és 3rd party programot sem használnak.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Lehet, hogy én nem látom, de itt csak a HD 7870 és a GTX 670 közötti különbséget látom. Nézd meg a diagrammot. A min és a max között alig van különbség van ahogy nálad is. Ezt egy légy sem látja, nemhogy egy ember.
Ráadásul ezek nem egymás utáni értékek. Akadást 60 hz-es monitorral 16 ms-nál nagyobb érték okoz. Ennek meg kell lennie, különben a kijelzőre kikerülő kép is lassabb, mint ahogy a gép dolgozik.Ha azt összegzem, amit mondasz, akkor nem a Radeonnal volt bajod, hanem azzal, hogy voltak olyan képkockák, amelyek számítása 16 ms-nál több ideig tartott. Ilyenkor erősebb hardver kell. Vettél egy erősebb hardvert, és ez most nincs. De ez nem a Radeon és a GeForce közötti különbség, hanem a hardver és a hardver közötti, amit a nyers teljesítmény ad.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Carrot007
#8500
üzenetére
Nem hülye, csak totálisan rossz végkövetkeztetéseket von le. De lassan látom mi volt a baja. Lassú volt a hardvere.
(#8501) TTomax: Nem kérek elnézést, csak megpróbálom elmagyarázni, hogy ez hogyan működik. Nem láthatsz akadást, ha nincs 16 ms fölött a frame idő. Értsd meg, hogy a monitorra nem kerül ki gyorsabban a kép. Ez fizikailag lehetetlen.
Általánosan találtak 5-30%-ot a játékokban. Ez volt a cél. A másik kérdés, hogy hogyan oszlik el, de ez már a motortól függ.
(#8503) kockaharcos: Erről beszélek, de mindegy. Ő a fejébe vette, hogy akadt és kész, és ezer százalék, hogy a hardverrel volt a baj, nem egy szoftverkörnyezeti probléma volt. Az adatok alapján viszont egy légy sem tudná megkülönböztetni, hogy melyik fut jobban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Na végre valami. Ez bizony akadás. 54 ms az már jóval több, mint a 16 ms. Viszont, ahogy látod ezt a CPU csinálta, vagyis az akadás a jelenet számításánál következett be (ekkor a GPU-hoz az adat még el sem ért). A GPU a zöld, és ott a max érték 8 ms, ami fele a 16 ms-nak. Ergo nem a GPU-tól volt erre konkrét bizonyíték a képed.
Egyébként ilyen akadást csinálhat olyan dolog, hogy például a rendszermemóriában nincs benne egy adat. Vagy a motor rosszul inicializálta a hardverkiépítésedet, így rossz beállítások születtek. Egy dolog nem növelheti meg így a CPU-időt, mégpedig a GPU mert arra nem tartozik a jelenetszámítás. Konkrétan vissza sem ír a rendszermemóriába.Nem értem, hogy miért ezekkel jössz. Világosan leírtam, hogy a képen látható, hogy a CPU okozza az akadást, és nem a GPU. Ha te ezt nem fogadod el, akkor a saját bizonyítékodnak mondasz ellent. Komolyan nézd meg, hogy a sárga csík az a CPU. Az a jelenet számítása. A GPU sosincs 16 ms fölött, vagyis a render jól van számolva. A GPU egy külön rendszer, ami visszafelé nem dolgozik. Az képet számol és kiküldi a monitorra. Ahhoz semmi köze, ami a jelenetszámítás szintjén zajlik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem ezzel van a baj, hogy neked mi a lényeg, hanem azzal, hogy azt állítod, hogy az akadást GPU okozta, amikor láthatóan a CPU. Csak ez az ami félrevezető, mert a saját bizonyítékod mond az állításodnak ellent.
Kapásból öt ismert és elismert képi hibát tudok felhozni GeForce driverrel, néhányuk több éves. Megint nem értem, hogy mit akarsz bizonyítani?
Ezt sem értem, hogy ilyen trollkodásra mi szükség van?
Egyébként a Catalyst sem csinálhat ilyet, mert az GPU driver. Annak a működését a zöld grafikon mutatja.
Nekem mindegy, hogy mit veszel, ha meg a lelked akarod ezzel nyugtatni, akkor azt nem hiszem, hogy itt és pont így kellene megtenni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Semmit. Az állításaidat cáfolom, és te is felhoztál egy képet, amivel megcáfoltad már.
Nem a tapasztalattal van baj, hanem a következtetéssel.
Én azt írom le neked, hogy amikor szervizes voltam, akkor rengeteg látszólag teljesen logikátlan megoldást találtam különböző problémákra. Bármelyik átlagember arra gondol, hogy ha kicserélsz egy hardvert egy másikra és a gond eltűnik, akkor valószínű, hogy az előző hardverrel volt a gond. A gond az, hogy ez nem triviális, ahogy a kép is mutatja a problémád forrása mélyebb. Az, hogy mitől volt, azt valszeg most már nem tudjuk meg, mert nem tudjuk elemezni a rendszert, de az világosan látszik, hogy a CPU dolgozott rosszul, de te a GPU-t teszed felelőssé.
De a Catalyst az miért felelne a processzorért? Ugyan ne viccelj már. Az azért felel, hogy az a zöld csík olyan legyen, amilyen nálad. Ennyi. Ne láss egy GPU driverbe többet, mert nincs benne több. Az Intel processzorát fel sem ismeri. Mit csinálhat neki? Mondja, hogy most laggolj úgy 50 ms-ot, mert én azt mondtam? Ilyen nem létezik. A GPU driver az a GPU-ért felel. Minden más tőle távol áll.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Attól, hogy te felelőssé teszel valamit még a képed teljesen másról árulkodik. Hidd el nekem, hogy minden GPU driver csak a GPU-ért felel. A CPU nem a reszortja, főleg nem az Intel CPU.
Nem tudom meddig akarod folytatni, de saját magad mutattad meg, hogy a CPU csinálja a lagot. Miért teszed felelősség a GPU-t érte, ami 8 ms-nál nagyobb frame időt nem is futott. Ez kezd boszorkányüldözésre hasonlítani, amikor minden tényszerű bizonyítéknak ellentmondva kikiáltod, hogy márpedig akkor is a GPU a bűnös, még ha az eredményei jók is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem értesz. Nem mondtam, hogy user error! Csak a kép alapján nem azt látom, hogy a GPU okozta. Ezernyi oka lehet annak, hogy a CPU időközönként 50 ms-os scene időt fut, de a GPU biztos nem oka, mert a jelenet számításánál még be sem kapcsolódott a munkába. Az előző képkockán dolgozik, mert ahhoz vannak adatai. Simán lehet valós probléma, biztos az, csak semmi sem utal arra, hogy a GPU okozta, sőt inkább ellene vall a kép.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nekem is mondta a szomszéd kislány unokabátyjának az mostohaanyja, hogy ... ilyen dolgokat oldalszámra lehet írni, amire elég felhozni a tesztek bizonyítékait cáfolatnak.
Akkor neked nem ér semmit a BF3 PH tesztje. Meggyőződésünk, hogy sokak értékelik.
A motor működése az adott játékban nem hardvertesztre tartozik. Ha minden bugos, vagy valamilyen szempontból nem elvárt eredményt teljesítő motort kivennénk a tesztekből, akkor nem lenne játék, amivel tesztelni lehet.
Valóban nem tökéletes a FrostBite 2 a BF3 alatt, de láttunk már bugosabb programokat is. Ez persze nem mentség, de annyira azért nem rossz a motor, hogy a szégyenfalra kerüljön, sőt, ha a nagy átlagot nézzük, akkor nagyon is jó motorról van szó.(#8558) SzlobiG: Nem WHQL a 310.70-es. Az NVIDIA sem írja annak, nem tudom, hogy a Guru3D honnan vette. Szimplán hivatalos béta ... olyan, amilyen a többi.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#8581
üzenetére
A BIOS-ban kapcsold be. Egyszerűbb programszinten kontrollálni ezt. De a BF3-ban már megoldották a négymagosokra. A kétmagosokon még előjövöget.
Ha az optimalizálásnál nem vették figyelembe a Hyper-Threadinget, akkor előfordulhat akadás máshol is. A legegyszerűbb gyógyír erre, hogy a feladatkezelőben a futtatott programnál az affinitásnál ki kell kapcsolni a páratlan szálakat. A 0, 2, 4, 6 ... legyen aktív. Ez a legegyszerűbb módja ezt kezelni, és nem is kell általánosan kikapcsolni.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
). A global illumination, ami terheli a kártyákat. Ugyanazt a megoldást használja, amit a CryEngine 3 (Light Propagation Volumes), csak sokkal több fényforrással, és compute shaderben van írva az egész. Kepleren én a GI kikapcsolását fontolnám meg, de ha nem kell 50-60 fps, akkor az MSAA nullázása is megoldás. Esetleg opció a Depth of Field minőségének csökkentése. Az is compute shaderben van írva.
Egyébként a Catalyst sem csinálhat ilyet, mert az GPU driver. Annak a működését a zöld grafikon mutatja.
Új hozzászólás Aktív témák
- Xbox Series X|S
- SörcsaPH!
- CURVE - "All your cards in one." Minden bankkártyád egyben.
- Politika
- Garancia kérdés, fogyasztóvédelem
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Kiszivárgott információk az új AMD chipek érkezéséről
- Milyen TV-t vegyek?
- Bivalyerős lett a Poco F6 és F6 Pro
- Kerékpárosok, bringások ide!
- További aktív témák...
