AMD-nVidia vita az új játékok sebessége miatt
Jelentkezz be a hozzászóláshoz.
#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ó.
az számit, hogy stabilan hány fps a cs, a többi túró.
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
#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."
#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ó.
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ó.
#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? 😄
Ugye nem hiszed azt, hogy azért fejlesztenek "jobb" videokártyát hogy a felhasználónak jó legyen? 😄
Vain ei kuulu terroristien käsiin! CS. N. T. K. K.! SG az a hely ahol sunyi módon csöndben törölgetik a hozzászólásokat, indok nélkül. ;)
#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.
"...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.
#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).
"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).
#43
Nvidia jött látott gyõzött!
#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.
...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.
#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...
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...
#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.
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.
Windows 7 & openSUSE 11.4 @ 64-bites kenyérpirító.
#39
Támogatják-e a gyártók a kiemelt fejlesztõket? Támogatják.
Azt díjazzák-e, ha a konkurencia kártyáján fut jobban? Nem valószínû.
Érdekük-e a gyártóknak, hogy újra és újra piaci igény keletkezzen a legújabb kártyákra, azok közül is a drágábbakra? Érdekük.
Akkor már csak össze kell adni.
Azt díjazzák-e, ha a konkurencia kártyáján fut jobban? Nem valószínû.
Érdekük-e a gyártóknak, hogy újra és újra piaci igény keletkezzen a legújabb kártyákra, azok közül is a drágábbakra? Érdekük.
Akkor már csak össze kell adni.
#38
"és a fejlesztõ is, ugyanis õk is pénzt kapnak a hardvergyártótól, hogy még véletlenül sem optimalizáljanak."
Ezt melyik ujjadból szoptad?
Ezt melyik ujjadból szoptad?
#37
Call of Juarez developer blasts Nvidia FUD attack link
"All DirectX 10 graphics hardware which supports MSAA is required to expose a feature called 'shader-assisted MSAA resolves' whereby a pixel shader can be used to access all of the individual samples for every pixel. This allows the graphics engine to introduce a higher quality custom MSAA resolve operation. The DirectX 10 version of 'Call of Juarez' leverages this feature to apply HDR-correct MSAA to its final render, resulting in consistently better anti-aliasing for the whole scene regardless of the wide variations in intensity present in HDR scenes. Microsoft added the feature to DirectX 10 at the request of both hardware vendors and games developers specifically so that we could raise final image quality in this kind of way, and we are proud of the uncompromising approach that we have taken to image quality in the latest version of our game.
"ExtraQuality" is a visual quality setting enabled by default in the DX10 version of Call of Juarez. In benchmark mode, "ExtraQuality" mode does two things. First, it increases shadow generation distance in order to apply shadowing onto a wider range of pixels on the screen, resulting in better quality throughout the benchmark run. Second, it increases the number of particles rendered with the geometry shader in order to produce more realistic-looking results, like for example waterfall, smoke and falling leaves. The attached screenshot illustrates those differences when ExtraQuality is disabled. ExtraQuality is designed as a default setting to reflect the visual improvements made possible by DX10 cards and is not meant to be disabled in any way.
All updates to shaders made in the final version of the Call of Juarez benchmark were made to improve performance or visual quality or both, for example to allow anisotropic texture filtering on more surfaces than before. This includes the use of more complex materials for a wider range of materials. At the same time we implemented shader code to improve performance on the more costly computations associated with more distant pixels,. Some materials were also tweaked in minor ways to improve overall image quality. One of the key strengths of NVIDIA’s hardware is its ability to perform anisotropic filtering at high performance so we are puzzled that NVIDIA complains about this change when in effect it plays to their strengths."
Szóval, beépítettek pár fícsört, ami az Nvidia kártyáknak jobban fekszik. Azt hitték, ezzel majd az Nvidia kedvében járnak. Csak azzal nem számoltak, hogy ez így sem fog tetszeni nekik, mert az õ kártyáikon is túl lassú. LOL.
"All DirectX 10 graphics hardware which supports MSAA is required to expose a feature called 'shader-assisted MSAA resolves' whereby a pixel shader can be used to access all of the individual samples for every pixel. This allows the graphics engine to introduce a higher quality custom MSAA resolve operation. The DirectX 10 version of 'Call of Juarez' leverages this feature to apply HDR-correct MSAA to its final render, resulting in consistently better anti-aliasing for the whole scene regardless of the wide variations in intensity present in HDR scenes. Microsoft added the feature to DirectX 10 at the request of both hardware vendors and games developers specifically so that we could raise final image quality in this kind of way, and we are proud of the uncompromising approach that we have taken to image quality in the latest version of our game.
"ExtraQuality" is a visual quality setting enabled by default in the DX10 version of Call of Juarez. In benchmark mode, "ExtraQuality" mode does two things. First, it increases shadow generation distance in order to apply shadowing onto a wider range of pixels on the screen, resulting in better quality throughout the benchmark run. Second, it increases the number of particles rendered with the geometry shader in order to produce more realistic-looking results, like for example waterfall, smoke and falling leaves. The attached screenshot illustrates those differences when ExtraQuality is disabled. ExtraQuality is designed as a default setting to reflect the visual improvements made possible by DX10 cards and is not meant to be disabled in any way.
All updates to shaders made in the final version of the Call of Juarez benchmark were made to improve performance or visual quality or both, for example to allow anisotropic texture filtering on more surfaces than before. This includes the use of more complex materials for a wider range of materials. At the same time we implemented shader code to improve performance on the more costly computations associated with more distant pixels,. Some materials were also tweaked in minor ways to improve overall image quality. One of the key strengths of NVIDIA’s hardware is its ability to perform anisotropic filtering at high performance so we are puzzled that NVIDIA complains about this change when in effect it plays to their strengths."
Szóval, beépítettek pár fícsört, ami az Nvidia kártyáknak jobban fekszik. Azt hitték, ezzel majd az Nvidia kedvében járnak. Csak azzal nem számoltak, hogy ez így sem fog tetszeni nekik, mert az õ kártyáikon is túl lassú. LOL.
#36
"zek is akkora marhaságok, hogy egy játékot csak bizonyos kártyákra fejelsztenek ki és nem gondolnak arra a cégek, hogy a legtöbb felhasználónak nincs még olyan videókártyája és egy vacak játék miatt nem is fog venni"
De kevesebb felhasználó viszont rohan az aktuális gf x800gtx-ért, vagy radeon xx950XTX-ért, és ezektbõl jól jár a hardvergyártó, és a fejlesztõ is, ugyanis õk is pénzt kapnak a hardvergyártótól, hogy még véletlenül sem optimalizáljanak.
De kevesebb felhasználó viszont rohan az aktuális gf x800gtx-ért, vagy radeon xx950XTX-ért, és ezektbõl jól jár a hardvergyártó, és a fejlesztõ is, ugyanis õk is pénzt kapnak a hardvergyártótól, hogy még véletlenül sem optimalizáljanak.
Vain ei kuulu terroristien käsiin! CS. N. T. K. K.! SG az a hely ahol sunyi módon csöndben törölgetik a hozzászólásokat, indok nélkül. ;)
#35
😄 eggyikel sem játszottam.. konkrétan a half lifeot rühellem..a rollecoaster tycoon meg csak az elsõ résznél volt az igaz 😄
#34
Egyet értek, mostmár inkább a mennyiség lett a fontosabb, mint a minõség. optimalizálásról sincs szó már szinte. Nekem Ati 9600 pro kártyám van, de most fogok bõvíteni. Bár õszintén szólva inkább a jövõ játékaiban bízok, amik majd kijönnek (Crysis, UT2007). Remélem ezeket nem szarják el úgy, mint a mostani legtöbb nextgen játékokat.
#33
Le kellene talán normálisan tesztelni azt a gámát mielõtt kiadják.
Nincs idejük optimalizálásra. Legyártják a gámát és már dobják is piacra.
Pénz, pénz, pénz....
Az ut2004, half life.... -nél még valahogy volt idejük rá.
Már nincs. 😊 és ez egyre jobban így lesz. 8800-as kártyán akadnak a játékok.
100 000Ft-os videokari felett ez már nem a kártya baja.
Már jónéhány éve semmi jó ötletet sem látni. Van kaland, stratégia, szimulátor, rpg...... Hol vannak a jó ötletek? Mint pl. a Bridge builder...
Ma már csak a shaderek számítanak?
Nincs idejük optimalizálásra. Legyártják a gámát és már dobják is piacra.
Pénz, pénz, pénz....
Az ut2004, half life.... -nél még valahogy volt idejük rá.
Már nincs. 😊 és ez egyre jobban így lesz. 8800-as kártyán akadnak a játékok.
100 000Ft-os videokari felett ez már nem a kártya baja.
Már jónéhány éve semmi jó ötletet sem látni. Van kaland, stratégia, szimulátor, rpg...... Hol vannak a jó ötletek? Mint pl. a Bridge builder...
Ma már csak a shaderek számítanak?
#32
Egyértelmû számomra hogy Nvidia 8800GTX-et veszek ez nállam nem is kérdés!
Bár most az Ati is belehúzott az olcsó de jó teljesitményû kártyáival.
De akkor is Nvidia. Mivel jön a Brother in arms Hell's Highway igy muszály fejleszteni a gépet, mert a 7800GT lehet hogy nem viszi majd le😊
Ezért géptunning😊))
Bár most az Ati is belehúzott az olcsó de jó teljesitményû kártyáival.
De akkor is Nvidia. Mivel jön a Brother in arms Hell's Highway igy muszály fejleszteni a gépet, mert a 7800GT lehet hogy nem viszi majd le😊
Ezért géptunning😊))
#31
Pfff... Régebben bezzeg nem voltak ilyen gondok! Lekellett volna ragadni egy Wolf3D szinten és most sem lennének ilyen gondok... Nem is érdemes már ilyenekkel foglalkozni. Én anno vettem egy radeon 9600-at és még most is azt használom. Blah nem megy rajta az új Colin McRae most mi lesz velem. Ezek is akkora marhaságok, hogy egy játékot csak bizonyos kártyákra fejelsztenek ki és nem gondolnak arra a cégek, hogy a legtöbb felhasználónak nincs még olyan videókártyája és egy vacak játék miatt nem is fog venni, vagy ha kidob több 10ezer Ft-ot egy vacak játék miatt, akkor úgy kell neki... Nah mindegy...
#30
Szerintem a grafikus engine-en is sik múlik.
Például nem véletlen, hogy a COD2 is a régi, Quake3 engine-jét használja, mert az elég hatékony.
Látván a rábízott feladatot, nem is szabadna szaggatnia egy valamire való kártyán DX7 alatt.
Például nem véletlen, hogy a COD2 is a régi, Quake3 engine-jét használja, mert az elég hatékony.
Látván a rábízott feladatot, nem is szabadna szaggatnia egy valamire való kártyán DX7 alatt.
#29
Nem értem mi az az iszonyat szuper extra dolog egy atiban vagy egy nvidiában ami miatt a program a másik kártyával nem fut rendesen (gondolom opengl-ben gl_nv_/gl_ati_ stb. kiterjesztéseket használnak leginkább, directx-nél viszont nem tudom).
De amúgy az hogy a gyártók egymást szidják elég vicces, egyértelmû hogy nem az õ hibájuk, hanem a készítõké. Meg amúgy is ha nem használnának mindenhez pikszelsédört és társait, akkor talán minden kártyával gyorsabban futnának. "Látványjavítás", persze, csak nem bírtak rendes textúrákat csinálni és így két gyors lépésben akarják helyrehozni, három bonyolultabb de jobb helyett.
De amúgy az hogy a gyártók egymást szidják elég vicces, egyértelmû hogy nem az õ hibájuk, hanem a készítõké. Meg amúgy is ha nem használnának mindenhez pikszelsédört és társait, akkor talán minden kártyával gyorsabban futnának. "Látványjavítás", persze, csak nem bírtak rendes textúrákat csinálni és így két gyors lépésben akarják helyrehozni, három bonyolultabb de jobb helyett.
Windows 7 & openSUSE 11.4 @ 64-bites kenyérpirító.
#28
Jeeee most már a videókártya gyártók is fakkolják a játékkészítõket, amiért lusták
NORMÁLISAN optimalizálni és a meglévõ hardveren élvezhetõ grafikájú programokat kiadni!
Eddig valószínû azért nem fakkoltak, mert tudtak a GPU gyártók hova fejlõdni,
és most úgy láccik, hogy a 8-as széria és a DX10 után már nincs élet...
NORMÁLISAN optimalizálni és a meglévõ hardveren élvezhetõ grafikájú programokat kiadni!
Eddig valószínû azért nem fakkoltak, mert tudtak a GPU gyártók hova fejlõdni,
és most úgy láccik, hogy a 8-as széria és a DX10 után már nincs élet...
#27
Nameg ha jól rémlik, akkor a Half Life 2 is ATI sponzorált játék.
#26
Roller Coaster Tyconn 3 nemcsakhogy lassabban fut nvidian, de még ki is fagy vele jónéhányszor! Elején ott virít az ATI
#25
dettó.. ATI logóval nem igazán futottam össze.. és fura módon egy hasonló kategóriás NV kari fura módon gyorsabb volt ugyanazzal a géppel ugyanazzal a játékkal..
#24
Hát én nvidia logót sokkal több játékban láttam mint atit. A Get In The Game talán egyedül a kill.switchbõl rémlik. De az is lehet, hogy máshol épp átléptem ESC-vel. <#vigyor5>
#23
lol bazze hát épp errõl szól a VGA piac...
Metallica. Csakis. Amig ki nem halnak. Easyrider öcsém, easyrider!
#22
leszarom,m veszek ket kartyat es egyik jatek ezen masik azon...<#idiota>
MJ rulz Pink Team The Only One
#21
Van egy egész jó kártyám, x800xl, 512mega, 16 pipa, 2*256busz... mégsem mennek az új játkékok, mert shader 3as kellene, ami ezen pont nincs, pedig a kártya sebessége még ma is kivánló, de nem ér már semmit... ez azért szemétség.
#20
Tökéltesen igaz, de én nem mondanám ezek miatt olyan hatékonynak azokat a vágásokat, leg jobb esetbe ha nyertek vele 1%-ot, akkor sokat mondtam. Viszont a shader cserélgetésekkel már akár 100%-ot is nyerhetnek, sõt nagy mozgások esetén még primitívebb shader is megteszi, ami meg még gyorsabb.
#19
Persze, de nyilván nem csak arról volt szó, amit bármely program is megcsinál.
#18
"Ha ezt minden játékban tudná, akkor nem lenne semmi gond."
Pedig meglehet csinálni BSP-fával Z-bufferrel és Occlusion Queryvel. A klamera látószögén kívûl esõdolgokat pedig minden megoldás vágja, egyszerû oko 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 tartizik?
Pedig meglehet csinálni BSP-fával Z-bufferrel és Occlusion Queryvel. A klamera látószögén kívûl esõdolgokat pedig minden megoldás vágja, egyszerû oko 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 tartizik?
#17
"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."
Nem csak ez volt a gond, hanem hogy nem volt semmi együttmûködés, így az ATI nem adhatott pl. tanácsokat a játékon belüli elvárható szintû optimalizációt tekintve sem.
"á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."
Nem csak azért, hogy tesztek alatt jól fusson. Egy sor játékra van optimalizálás, nem csak azokra, amivel tesztelni szoktek.
(Itt az "optimalizálás" már nem csalást jelent, mint régebben.)
Nem csak ez volt a gond, hanem hogy nem volt semmi együttmûködés, így az ATI nem adhatott pl. tanácsokat a játékon belüli elvárható szintû optimalizációt tekintve sem.
"á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."
Nem csak azért, hogy tesztek alatt jól fusson. Egy sor játékra van optimalizálás, nem csak azokra, amivel tesztelni szoktek.
(Itt az "optimalizálás" már nem csalást jelent, mint régebben.)
#16
Ha ezt minden játékban tudná, akkor nem lenne semmi gond. De ha csak úgy tudja, ha elõre megvan az egész kameramozgás, akkor már kicsit más a dolog... Kicsit nem lesz reprezentatív a teszt eredménye.
#15
DOOM3-nál más is közre játszott: abban a driverben cserélte le az nvidia az addigi Ultra shadow emulációját hardwaresre.
A stencil árnyék demó programok is felgyorsúltak, ha tudták az Ultra shadow-t.
A stencil árnyék demó programok is felgyorsúltak, ha tudták az Ultra shadow-t.
#14
Aki ilyen aproságokon fent akad, hogy csalnak a Videokártya gyártok a tesztejben és a játékokban az valószinûleg "túl fiatal vagy túl hiszékeny". Nem ez volt az elsõ csalás volt az Ati-nak 2000-ben egy "csunya esete" a Quake 3-al az nvidiának Doom 3-al( a v56.76 utáni driverel 100%-ot gyorsult a GF5600-os FPS-e ) de valószinûleg nem is az utolsó.
#13
én lefutattam a call of juarez dx10 benchmarkot egy 8800 gts 320 mb-os vga-val
az átlag fps 15 lett
na ez a nem semmi, úgyhogy valami lehet a dologban
az átlag fps 15 lett
na ez a nem semmi, úgyhogy valami lehet a dologban
#12
Ja, sorry. Már írták elõttem, némivel bõvebben 😊
Mea culpa
Mea culpa
A világ Szentháromsága: a Pénz, a Jog, a Marketing
#11
Volt ilyen, bizony. A "nagy benchmark-botrány". Mindenki szeretett 3DMarkja ágyba bújt az Nvidiával.
A világ Szentháromsága: a Pénz, a Jog, a Marketing
#10
Én lényegében nem tudom hogy ez milyen formában lehet, de annyi biztos hogy annak nem szabadna elõfordulnia hogy a más névvel ellátott driverelt hardver más eredményt mutasson..
#9
OK! Az egy dolog, hogy levágták a sarkokat, de normál kamera nézetben pontosan ugyan azt kellet kirajzolnia, mint amit engedtek neki, így gyakorlatilag semmit sem gyorsítottak, fõleg, hogy processzor már elõkészített mindent, és detektálni sem könnyû azokat a helyeket csak úgy software-bõl. Konkrétan csak a "freelokk"-nál jelentett ez optimalizációt.
Én a botránnyal kapcsolatban konkrétan arról tudok, hogy az nvidia driverek pofátlanul felismerték a 3DMark03-at, majd nem azokat a shadereket töltötték fel, mint amit a 3DMark-osok beadtak. Sokkal kisebb precizitású és rondább képminõséget produkáló shadereket használt így a kártya a testek futása során, melyek természetesen sokkal gyorsabban futottak le. Ezért komolyan reklamált a Futuremark is akkoriban
Én a botránnyal kapcsolatban konkrétan arról tudok, hogy az nvidia driverek pofátlanul felismerték a 3DMark03-at, majd nem azokat a shadereket töltötték fel, mint amit a 3DMark-osok beadtak. Sokkal kisebb precizitású és rondább képminõséget produkáló shadereket használt így a kártya a testek futása során, melyek természetesen sokkal gyorsabban futottak le. Ezért komolyan reklamált a Futuremark is akkoriban
Kép1
Most nem állok neki végigtúrni a netet, a lényege az volt, persze ha jól emlékszem, hogy a 3dmark regisztrált változatában volt egy "free move" mód, ahol a kamerát lehetett forgatni a teszt közben, kvázi körbe lehetett nézni, és az nvidia driverekkel csak ott volt kép, amerre a normál tesztben a kamera néz, a többi hasonlóképpen nézett ki mint a linkelt kép.
Csak találtam cikket róla, ha érdekel, angolul elolvashatod itt
Most nem állok neki végigtúrni a netet, a lényege az volt, persze ha jól emlékszem, hogy a 3dmark regisztrált változatában volt egy "free move" mód, ahol a kamerát lehetett forgatni a teszt közben, kvázi körbe lehetett nézni, és az nvidia driverekkel csak ott volt kép, amerre a normál tesztben a kamera néz, a többi hasonlóképpen nézett ki mint a linkelt kép.
Csak találtam cikket róla, ha érdekel, angolul elolvashatod itt
#7
"Az ominózus probléma az volt, hogy az NVIDIA driverbõl felismerte a 3dmarkot, és a kamera látószögén kívüli részt egészen egyszerûen nem renderelte a teszt alatt, nemkis balhé volt."
és itt hol az az speciális nvidia optimalizáció, 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. Már a BSP-fával is lehet hasonló optimalizációt csinálni.
és itt hol az az speciális nvidia optimalizáció, 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. Már a BSP-fával is lehet hasonló optimalizációt csinálni.
#6
(ha vip vagy, tudsz javítani)
Francba, miért nincs javítás opció?
Az ominózus probléma az volt, hogy az NVIDIA driverbõl felismerte a 3dmarkot, és a kamera látószögén kívüli részt egészen egyszerûen nem renderelte a teszt alatt, nemkis balhé volt.
Az ominózus probléma az volt, hogy az NVIDIA driverbõl felismerte a 3dmarkot, és a kamera látószögén kívüli részt egészen egyszerûen nem renderelte a teszt alatt, nemkis balhé volt.
Az ominózus probléma az volt, hogy az NVIDIA friverbõl felismerte a 3dmarkot, és a kamera kívüli részt egészen egyszerûen nem renderelte a teszt alatt, nemkis balhé volt.
hmm mintha lett volna egy ilyen túlzott driveroptimalizáció. asszem az NV valami 25%ot csalt össze a benchmarkon meg pár játékon.. persz kiderült hogy az ati is csalt.. bár nála csak 5% volt a csít.. de mindenki elfelejtette az NV dolgát.. én nem..
#2
Itt most nem arról van szó. A fõ probléma az, hogy az Nvidia-khoz másképpen kell optimalizálni a shadereket és más képpen az ATI-khoz.
nem tudom, mennyi értelme van ezeknek a logóknak.
annak idején a Half Life 2 source engine-jét bevallottan Atira fejlesztették, nekem a radeon 9800-on és az x1600-on is szépen futott.
aztán a Sin: Episodes és a Dark Messiah of Might and Magic - mindkettõ Source engine-es játék - nvidia TWIMTBP logóval jött ki. hirtelen átírták az licenszelt engine-t nvidiára? :o
annak idején a Half Life 2 source engine-jét bevallottan Atira fejlesztették, nekem a radeon 9800-on és az x1600-on is szépen futott.
aztán a Sin: Episodes és a Dark Messiah of Might and Magic - mindkettõ Source engine-es játék - nvidia TWIMTBP logóval jött ki. hirtelen átírták az licenszelt engine-t nvidiára? :o