Gyurkity Péter

AMD-nVidia vita az új játékok sebessége miatt

Az AMD és az nVidia egyaránt tiltakozik egyes újabb játékok sebessége miatt, mivel azok állítólag rossz színben tüntetik fel saját termékeiket. A rossz benchmark eredmények miatt egymást, illetve a fejlesztő cégeket okolják.

Az X-bit Labs részletes összefoglalóban számolt be a két gyártó egymással, illetve egyes játékfejlesztő cégekkel folytatott vitájáról, amely ismét néhány játék sebessége kapcsán robbant ki. Mindkét óriás a rossz eredmények miatt igyekszik tisztára mosni magát, ám míg az AMD legfőbb riválisával veszekszik, az inkább egy harmadik cégen verné el a port.

A sort az AMD nyitotta meg, amely a Lost Planet: Extreme Condition kapcsán közölte kifogásait. Ez a játék ugyanis a Radeon kártyákkal rossz eredményt produkált, amit a gyártó azzal magyarázott, hogy a fejlesztés az nVidia "The way it's meant to be played" (TWIMTBP) programjának része és mint ilyen, a rivális cég számára engedett bepillantást idejekorán a kódba, lehetővé téve a meghajtók optimalizálását. A játékot fejlesztő Capcom eleddig nem reagált a bejelentésre, ám némiképp elgondolkoztató, hogy az AMD erre, vagyis a meghajtók optimalizálásra hivatkozik, hiszen ez egyben annak beismerése is, hogy olykor a gyártók kifejezetten egyes címekre hegyezik ki termékeiket, hogy a tesztek során jól szerepeljenek.


Az nVidia eközben a Call of Juarez-t fejlesztő Techland felett tört pálcát, amiért annak fejlesztése pocsékul muzsikál a GeForce 8-as kártyák alatt. Állítólag néhány változtatás miatt fordulhatott ez elő, amely a sebesség drasztikus romlását idézte elő, az nVidia pedig egyenesen azt állítja, hogy a rejtett opció miatt következett be a visszaesés. Szerintük ez extrém grafikai beállításokat erőltet rá a tesztprogramra, ráadásul semmilyen látható javulást nem eredményez a kinézetben, míg a Techland arra hivatkozik, hogy mindez a DirectX 10 részeként valósult meg és semmiképp nem ajánlott kikapcsolni. A meddő vita eredményeként alaposan megromlott a két cég kapcsolata, megoldást pedig egyelőre nem találtak.

Akiben a fenti veszekedés emlékeket ébreszt fel, az minden bizonnyal a 2003-as 3DMark kapcsán kirobbant botrányra gondol vissza, amelyben súlyos vádak hangoztak el mindkét részről. Az nVidia akkor a Futuremarkot hibáztatta a frissítés egyes változtatásai kapcsán, míg a népszerű tesztprogramot fejlesztő cég igyekezett tisztára mosni magát és egyben rávilágítani az nVidia felelősségére.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • irkab1rka #49
    ki nem szarja már le a tesztcégeket.

    az számit, hogy stabilan hány fps a cs, a többi túró.
  • Totigyerek #48
    Na a linkelt képekhez még dx 9 sem kell. A dx9 és 10 közötti különbség a crysis összehasonlító demójánál látszik. Persze lehet hogy ott is egy kicsit "rájátszotak."
  • dez #47
    "Most nem azért de a linknél a dx9 és dx10 között annyi különbséget látok, hogy a távoli sziklának más a textije. Ehhez szerintem nem kell dx10..."
    Hát ja. Bár gagyognak valamit Geometry shaderrel sokszorosított részecskékről, de ebből nem sokat látni.

    "Antialiasingnál meg szerintem baromi sokat dobna a sebességen ha a fejlesztők megoldanák, hogy csak az éleket rajzolják újra a simításnál, nem pedig az összes polygont."
    A MSAA eleve arra épül, hogy csak a poligonok szélei mentén dolgozik. A belső részeken az AF textúraszűréssel érhető el hasonló.
  • Sanyix #46
    Egyértelmű hogy így megy, világos mint a nap...
    Ugye nem hiszed azt, hogy azért fejlesztenek "jobb" videokártyát hogy a felhasználónak jó legyen? :D
  • 1011001 #45
    A1274815-nek:

    "...A klamera látószögén kívűl eső dolgokat pedig minden megoldás vágja, egyszerű okok miatt. Hova rajzoljam a kamera mögötti dolgokat? Illetve még érdekesebb. Hova rajzoljam a kamera látószögén kívűl eső dolgokat, hiszen azokhoz még memória terület sem tartozik?" - ez nem pont így működik. A vágás már csak az inkrementális képszintézis utolsó szakaszában, a vetítési transzfromáció után a raszterizálásnál történik meg. Addig a csúcspontoknak át kell menniük a vertex shaderen (régebben a T&L végezte a feladatot, még régebben a CPU), melynek során a vertexek koordinátáit a kamera koordinátarendszerébe transzformálják. Általános esetben még ekkor sem lehet tudni, hogy mi fog látszani. Még az is elképzelhető, hogy olyan háromszöget látunk, melynek csúcspontjai kívül esnek a látható tartományon, de elég nagy, hogy "betakarjon" a képbe. Szóval ha valahol inkorrekten tudtak spórolni, akkor a vertexszámításon, mert előre tudták, mely háromszögek lesznek láthatóak, a többi pedig nem ment át a pipeline-on. A belinkelt kép alapján elképzelhetőnek tartom.

    "...egyetlen szutyok kártya sem vagy software render sem rajzol a kamera látószögén kívül le semmit, sőt még a takarásban lévő dolgokat sem, ha a program normálisan van megírva, ha nincs normálisan megírva akkor pedig azokat a dolgokat pontosan egyszer rajzolja le." - lásd a fenti bekezdést.
  • 1011001 #44
    A1274815-nek:
    "legjobb esetbe ha nyertek vele 1%-ot, akkor sokat mondtam" - Igen jól tájékozott vagy. :-) Saját tapasztalataim szerint a vertexszámítás igenis költséges. Az általam fejlesztett játékban opcionálisan bekapcsolható volumetrikus árnyékolás gyakorlatilag csak vertex-számítást használ, ugyanis a kirajzoláskor nem kell színinformáció, csak a stencil-buffert módosítom Z-fail teszttel (Carmack's reverse, lásd wikipedia). Ez plusz két renderelési ciklust jelent az egyébként is lefutó kettőhöz képest (a diffúz és spekuláris fényt külön ciklusban kell hozzáadni az árnyékkezelés miatt), így 44-ről 27 FPS-re csökken a teljesítmény (GF Go7300). Látható, hogy csak a vertexszámítást tartalmazó renderelési ciklusok közel annyi időbe telnek, mint a teljes renderelési ciklusok, ahol a pixel-shader kódban képpontonként textúra-mintavételezés is történik (az én esetemben nem is kevés: három).
  • Oblivion 5 #43
    Nvidia jött látott győzött!
  • Wittgen #42
    Manapság ez már nem hír, hogy játékok a legdurvább konfigokon is akadoznak. A játékkiadók/fejlesztők minél előbb pénzt akarnak látni a befektetésükből, ezért egyre rövidebb időt engednek a fejlesztésre és még rövidebbet a tesztelésre/optimalizálásra. 8-10 éve valahogy még adtak a kód optimalizálására (kivéve talán a SiN) de manapság....

    ...meg uyge itt ez a shader őrület. Nekem is egy x800gto-m van, de az új progik már basznak elindulni rajta, mivel nem rudja a PS3.0-át, pedig a teljesítményével nincs gond. De ezzel meg úgy vagyok, hogy f*szom ezekbe a játékokba, van elég jó másik is, amikkel el lehet lenni (pes, cod, homm3 és 5, wc3, meg pár rpg). Úgyhogy majd veszek akkor ps3.0-t tudó vidkarit, amikor majd olcsó lesz. Ja, van olcsó most is, de a teljesítményük hagy némi kifogásolni valót.
  • tviktor #41
    Én inkább úgy fogalmaznék, hogy kiadnak egy játékot úgy, hogy éppen csak megcsinálták a 3D részét, persze szinte mindenkinek akadozik.
    Ezután 3-6 hónappal "hihetetlen" módon sikerül optimalizálni a grafikát és a régebbi videókártyák is remekül elboldogulnak már vele.
    Mindenesetre addig a 3-6 hónapig lesznek olyan emberek, akik csak e miatt veszenk új kártyát.
    Ki van ez találva...
  • Lost Lont #40
    Most nem azért de a linknél a dx9 és dx10 között annyi különbséget látok, hogy a távoli sziklának más a textije. Ehhez szerintem nem kell dx10... Antialiasingnál meg szerintem baromi sokat dobna a sebességen ha a fejlesztők megoldanák, hogy csak az éleket rajzolják újra a simításnál, nem pedig az összes polygont.
    Ezek az összehasonlító képek meg mindig sántítanak valahol. Pl a bumpmap megjelenésekor ugyanazt a textúrát hasonlították össze bumpmap nélkül és azzal, persze hogy így sokkal szebb az utóbbi. A korábbi textúrákon ugyanis már "beépítve" voltak az árnyékok, azzal viszont hogy egy bumpmapre tervezett textit bumpmap nélkül mutatnak meg, kicsit rondán tüntetik fel.