FutureMark har stoppet Nvidia fra å jukse

[Vice]

Som det er blitt skrevet i flere innlegg tidligere i tråden: ALLE standard benchmark er like lette å jukse i (jeg vil ikke bruke ordet optimalisering, denne formen for koding har intet med optimalisering å gjøre). En innebygget standard flyby-sekvens i Unreal Tournament (og alle andre spill med innebygget benchmarkrutine) er akkurat like lett å jukse i som 3dmark. Forskjellen er imidlertid at programmererne av Unreal Tournament (og andre spill) ikke bryr seg med å sjekke om en skjermkortdriver jukser i deres benchmark. Hvorfor er det da en ulempe at Futuremark bryr seg med å sjekke? Og hvorfor gjør dette 3dmark til en dårligere test enn spill?

Forskjellen er at dersom skjermkortfabrikantene gjør det de kan for å få deres kort til å yte mest mulig i feks. Unreal, da kommer hvertfall dette brukerene tilgode ved at deres kort yter maksimalt i Unreal. Om de yter bra i 3dmark under optimaliserte(evt, jukse) drivere så får brukeren null og niks igjen av praktisk verdi. For hvem sitter vel og kjører 3Dmark hele dagen?(Sikkert noen )

Selvfølgelig er det helt forkastelig å lage drivere som feks. automatisk skifter antall bitplan med tanke på ytelse., men dersom Nvidia klarer å implementere en eller annen supersmart klippealgoritme som klipper alle quake/unreal/halflife-engine spill bedre enn det de klarer selv, ja da vil jeg mye heller ha slike drivere, selv om jeg får 1 i 3dmark score.

[Duke Soforth]

Forskjellen er at dersom skjermkortfabrikantene gjør det de kan for å få deres kort til å yte mest mulig i feks. Unreal, da kommer hvertfall dette brukerene tilgode ved at deres kort yter maksimalt i Unreal. Om de yter bra i 3dmark under optimaliserte(evt, jukse) drivere så får brukeren null og niks igjen av praktisk verdi. For hvem sitter vel og kjører 3Dmark hele dagen?(Sikkert noen   )

Selvfølgelig er det helt forkastelig å lage drivere som feks. automatisk skifter antall bitplan med tanke på ytelse., men dersom Nvidia klarer å implementere en eller annen supersmart klippealgoritme som klipper alle quake/unreal/halflife-engine spill bedre enn det de klarer selv, ja da vil jeg mye heller ha slike drivere, selv om jeg får 1 i 3dmark score.

Nei, du misforstår stadig. Hele poenget her er jo at det kan gjøres en "optimalisering" i driveren der det sjekkes om for eksempel benchmarksekvensen Antabus flyby gjøres. Stort sett alle benchmark som blir gitt i spill gjøres i demoer som er konstante og innebygde i spillet. Dermed kan det gjøres ugne ting med rendering på akkurat samme måte som det nå er avslørt i 3dmark. Men dette vil IKKE komme deg til gode når du spiller! Disse "optimaliseringene" er helt avhengig av at ting er konstant, så snart du setter deg ned og spiller skjer ting tilfeldig.

[Vice]

Nei, du misforstår stadig. Hele poenget her er jo at det kan gjøres en "optimalisering" i driveren der det sjekkes om for eksempel benchmarksekvensen Antabus flyby gjøres. Stort sett alle benchmark som blir gitt i spill gjøres i demoer som er konstante og innebygde i spillet. Dermed kan det gjøres ugne ting med rendering på akkurat samme måte som det nå er avslørt i 3dmark. Men dette vil IKKE komme deg til gode når du spiller! Disse "optimaliseringene" er helt avhengig av at ting er konstant, så snart du setter deg ned og spiller skjer ting tilfeldig.

Jeg ser ikke for meg flybys og slike konstante scriptede eventer når jeg sier at jeg foretrekker tester som er baserte på eksisterende enginer.

Disse kan jo som du sier fortsatt manipuleres sådan.

 

Det jeg ønsker dersom jeg skal teste ytelse, er som nevnt, testing med eksisterende engines og ikke noe proprietær engine/ scriptede eventer som i 3Dmark. Testen bør feks bestå av en bot-match kjørt et antall ganger hvor feks. score beregnes utifra peak,low,average fps. etc.

[Duke Soforth]

Jeg ser ikke for meg flybys og slike konstante scriptede eventer når jeg sier at jeg foretrekker tester som er baserte på eksisterende enginer. Disse kan jo som du sier fortsatt manipuleres sådan. Det jeg ønsker dersom jeg skal teste ytelse, er som nevnt, testing med eksisterende engines og ikke noe proprietær engine/ scriptede eventer som i 3Dmark. Testen bør feks bestå av en bot-match kjørt et antall ganger hvor feks. score beregnes utifra peak,low,average fps. etc.

Litt enig. MEN: skal du klare å kjøre en test som gir en meningsfylt sammenligningsverdi, så må du kjøre et script som er felles for alle kortene som testes. Og dersom du skal være helt sikker på at dette scriptet ikke kan "optimaliseres" for, så må du holde dette for deg selv. Det vil altså si at for eksempel hardware.no i sine fremtidige skjermkorttester må lage egne script for Serious Sam, Unreal Tournament osv., script som de ikke kan la være tilgjengelig offentlig. En (tilfeldig?) bot-match som kjøres flere ganger kan godt være en form for løsning, for å hindre for stor variasjon i verdier bør det imidlertid være ganske mange repetisjoner...

 

Se denne tråden for noen tanker rundt benchmarking.

[Cappo]

En interessant tankerekke, bare litt uheldig at du ikke ser konsekvensen av den. Dersom en produsent av et skjermkort lager et kort som lover gull og grønne skoger og som kommer med en driver som scorer supert i 3dmark og standardbenchmarkene de fleste reviewere bruker... kan du da utfra testen stole på at kortet vil yte bra når du spiller? Tror du burde lese hele tråden, og ikke minst kanskje tenke litt mer over hva benchmarking egentlig er.

Jeg vet hva benchmarking er. Jeg vil ikke at de skal teste noen forbanna bot tester, eller en eller annen fordømte flyby møkk i UT2003. Jeg vil at de skal sette seg ned å spille spilla. Det er da vi får det virkelige ytelses inntrykket.

[Duke Soforth]

Jeg vet hva benchmarking er. Jeg vil ikke at de skal teste noen forbanna bot tester, eller en eller annen fordømte flyby møkk i UT2003. Jeg vil at de skal sette seg ned å spille spilla. Det er da vi får det virkelige ytelses inntrykket.

Naturligvis. Jobben som reviewer er dog sannelig ikke enkel: for det første har de gjerne ikke ubegrenset tid til å leke med ting. For det andre er etterrettelighet et mål de hele veien må strebe mot for å unngå fanboy-stempel i forskjellige retninger. Tror jeg må tolke deg dithen at vi i fremtiden kan klare oss med skjermkorttester som ikke inneholder grafer, bare skjermbilder og en subjektiv opplevelsesvurdering fra review-forfatteren. Fint og flott og ikke nødvendigvis galt. Men veldig vanskelig. Og potensiale for noen fantastisk underholdende krangler...

[Duke Soforth]

Oh dear... har snøballen begynt å rulle?

In the past few days, Brent of HardOCP brought to light (to Dave) something he noticed while running this demo of ours (and I do mean our demo, not actually playing the game in that level) on a GFFX 5900Ultra. This demo has an ocean in its scene (a BIG ocean) and the entire ocean surface has two ps_1_1 shaders to effect, well, an ocean's surface.

 

I know exactly what those two ps_1_1 shaders codes are (unfortunately I can't provide them -- Ubisoft doesn't want me to) and those codes mean that "waves/ripples" should be rendered over the entire ocean's surface. Brent noticed that there are a number of spots where there are no "waves/ripples" on his 5900Ultra using 44.03s. Dave and I have confirmed that this "anomaly" happens only on 5600 and up but not on a 5200. I can confirm that both the demo and in actual gameplay in that level do not show up any such bug on a 5200 and Dave will investigate whether the bug exists in both the demo and in the gameplay level on a 5600 and above.

 

Sorry if you're asking for screenshots to depict what my attempt above to describe it -- I don't think it is right to provide these and fuel speculations until we get to the bottom of what's happening.

 

Dany Lepage (Ubisoft) has provided a very rough comment and I don't want to quote him in its entirety except that he thinks it is "definitely a driver bug". The thing is that we're trying to figure out why this "bug" exists on NV30/31/35 and not on NV34 even with NVIDIA's Unified Driver Architecture.

 

As for why Dave is highly suspicious, I have found out (and told Dave) that NVIDIA has a personnel focussed solely on SplinterCell benchmarking.

(fra Beyond3d)

[MistaPi]

Syns det er morsomt at Ati-fans avfeier Ati sitt eget juks med Q3(quakk testen...) med at de lanserte drivere som var bedre seinere... Mens når NVidia jukser så er det helt forferdelig! Er logikken her at hvis NVidia kommer med drivere som er bedre, uten juks, på ett senere tidspunkt så er de tilgitt?

 

Som sagt så påstår jeg ingenting, mao jeg avfeier ikke muligheten for at det faktisk var en cheat fra ATI sin side. Men hvis siutasjonen hadde vært lignende nå med at det hadde vært betydelig nedgang i grafikken som nvidia hevder er pga en driver bug og dem hadde lansert en driver like etterpå som hadde fikset problemet uten at ytelsen hadde gått ned så hadde jeg trodd Nvidia på det.

 

Og det var jo neste poenget mitt, bildekvalitet er viktigere enn performance i mine øyne. Så hvis du sitter å ser på ett skjermkort som gir deg 100000 i score i 3dmark03 og billedkvaliteten er crap så er det vel ingen som gidder å kjøpe dette? Og hvis Nvidia har klart å lage en teknikk som gjør 16 bits like pent som 32 bit UTEN å ødelegge bildekvaliteten så ser jeg på dette som en revolusjon og ikke som juks! Hihi.

 

Det er snakk om FP så forskjellen er nødvendigvis ikke så stor, men det er forskjell og siden det er full presisjon som skal bli kjørt på 3DMark03 så er det uansett juks, FP16 går ikke engang under PS2.0 spec'en.

Kortene skal testes på likt grunnlag der det er mulig, dvs ikke noe IHV spesifikke extensions, codepaths eller andre IHV spesiefikke optimaliseringer, sånn sett kan 3DMark03 være et nyttig verktøy selv om det ikke gir et riktig bilde av faktisk spill ytelse.

[Ikon]

Syns det er morsomt at Ati-fans avfeier Ati sitt eget juks med Q3(quakk testen...) med at de lanserte drivere som var bedre seinere... Mens når NVidia jukser så er det helt forferdelig! Er logikken her at hvis NVidia kommer med drivere som er bedre, uten juks, på ett senere tidspunkt så er de tilgitt?

 

Som sagt så påstår jeg ingenting, mao jeg avfeier ikke muligheten for at det faktisk var en cheat fra ATI sin side. Men hvis siutasjonen hadde vært lignende nå med at det hadde vært betydelig nedgang i grafikken som nvidia hevder er pga en driver bug og dem hadde lansert en driver like etterpå som hadde fikset problemet uten at ytelsen hadde gått ned så hadde jeg trodd Nvidia på det.

 

Og det var jo neste poenget mitt, bildekvalitet er viktigere enn performance i mine øyne. Så hvis du sitter å ser på ett skjermkort som gir deg 100000 i score i 3dmark03 og billedkvaliteten er crap så er det vel ingen som gidder å kjøpe dette? Og hvis Nvidia har klart å lage en teknikk som gjør 16 bits like pent som 32 bit UTEN å ødelegge bildekvaliteten så ser jeg på dette som en revolusjon og ikke som juks! Hihi.

 

Det er snakk om FP så forskjellen er nødvendigvis ikke så stor, men det er forskjell og siden det er full presisjon som skal bli kjørt på 3DMark03 så er det uansett juks, FP16 går ikke engang under PS2.0 spec'en.

Kortene skal testes på likt grunnlag der det er mulig, dvs ikke noe IHV spesifikke extensions, codepaths eller andre IHV spesiefikke optimaliseringer, sånn sett kan 3DMark03 være et nyttig verktøy selv om det ikke gir et riktig bilde av faktisk spill ytelse.

 

Vel hvis alle grafikk kort hadde fungert på samme måte så hadde jo det vært sant. Men slik er det nok ikke. Både Nvidia og Ati bruker egne extensions i både directX og OpenGL. Dette er noe developers må kode direkte for. Så det fungere ikke på samme måte hverken på kortene, driverene, opengl/dx eller i 3dmark03.. Synd men sant.

[MistaPi]

Det er snakk om FP så forskjellen er nødvendigvis ikke så stor, men det er forskjell og siden det er full presisjon som skal bli kjørt på 3DMark03 så er det uansett juks, FP16 går ikke engang under PS2.0 spec'en.  

Kortene skal testes på likt grunnlag der det er mulig, dvs ikke noe IHV spesifikke extensions, codepaths eller andre IHV spesiefikke optimaliseringer, sånn sett kan 3DMark03 være et nyttig verktøy selv om det ikke gir et riktig bilde av faktisk spill ytelse.

 

Vel hvis alle grafikk kort hadde fungert på samme måte så hadde jo det vært sant. Men slik er det nok ikke. Både Nvidia og Ati bruker egne extensions i både directX og OpenGL. Dette er noe developers må kode direkte for. Så det fungere ikke på samme måte hverken på kortene, driverene, opengl/dx eller i 3dmark03.. Synd men sant.

 

Spill utviklerene må vel ikke bruke vendor spesifikke extensions? OpenGL ARB2 f.eks er vel en generell extension/codepath? Det er vel noe av poenget med et syntetisk benchmark, at det ikke skal være vendor sesifikke optimaliseringer som å bytte ut shader kode.

[Ikon]

Det er snakk om FP så forskjellen er nødvendigvis ikke så stor, men det er forskjell og siden det er full presisjon som skal bli kjørt på 3DMark03 så er det uansett juks, FP16 går ikke engang under PS2.0 spec'en.  

Kortene skal testes på likt grunnlag der det er mulig, dvs ikke noe IHV spesifikke extensions, codepaths eller andre IHV spesiefikke optimaliseringer, sånn sett kan 3DMark03 være et nyttig verktøy selv om det ikke gir et riktig bilde av faktisk spill ytelse.

 

Vel hvis alle grafikk kort hadde fungert på samme måte så hadde jo det vært sant. Men slik er det nok ikke. Både Nvidia og Ati bruker egne extensions i både directX og OpenGL. Dette er noe developers må kode direkte for. Så det fungere ikke på samme måte hverken på kortene, driverene, opengl/dx eller i 3dmark03.. Synd men sant.

 

Spill utviklerene må vel ikke bruke vendor spesifikke extensions? OpenGL ARB2 f.eks er vel en generell extension/codepath? Det er vel noe av poenget med et syntetisk benchmark, at det ikke skal være vendor sesifikke optimaliseringer som å bytte ut shader kode.

 

Må nok det desværre. Ofte man kommer borti problemer i både drivere/dx/ogl som gjør at man må kode spesifikt for hvert kort. Litt kjipt egentlig.

[rvenes]

http://www.itavisen.no/art/1301255.html

 

NÆÆÆMEN... ATI har vist ikkje heilt reint mel i posen heller.

 

HIrr...

[Mr.Garibaldi]

http://www.itavisen.no/art/1301255.html

 

NÆÆÆMEN... ATI har vist ikkje heilt reint mel i posen heller.

 

HIrr...

 

Tja... Synes jeg sa det helt i starten av denne tråden (se side 1)...

 

Men siden du er så flink til å linke...

Kan du ikke link til hva Sweeney og Carmack har sagt om dette?

 

I følge deres definisjoner er ikke hva ATI har gjort juks....!

 

Og en annen ting, legg merke til hvordan ATI talket dette i forholdt til Nvidia...

 

Nvidia "Det er en bug, og FM har kodet programmet så vi ikke kan kjøre det ordentlig..."

ATI "Ja, vi har optimisert for 2 shadere i GT4. Vi vil fjerne dem i neste release...."

 

Mr.G (Som må løpe for å nå bussen!)

[Alastor]

http://www.itavisen.no/art/1301255.html

 

NÆÆÆMEN... ATI har vist ikkje heilt reint mel i posen heller.  

 

HIrr...

 

Det sto i den originale posten...OLD!

Og du fant det ikke ut før det kom på ITavisen av alle steder?

[Mr.Garibaldi]

Selvfølgelig er det helt forkastelig å lage drivere som feks. automatisk skifter antall bitplan med tanke på ytelse., men dersom Nvidia klarer å implementere en eller annen supersmart klippealgoritme som klipper alle quake/unreal/halflife-engine spill bedre enn det de klarer selv, ja da vil jeg mye heller ha slike drivere, selv om jeg får 1 i 3dmark score.

 

Klippefunksjon i spill? *grøss*

 

Tenk deg hvordan det vil være hvis drivern setter ett plane feil...

Plutselig får du samme effekt som når du går ut av brettet i no-clip mode...

 

Utrolig festlig hvis det skjer i en deathmatch...

Og hvis det kan skje en gang, vil det garantert skje flere ganger...

"Oops, der snudde jeg meg for fort igjen... Hvor lang tid tar det før drivern merker det, og rendrer det den skal igjen?"...

 

Nei, takke meg til HSR...

Ja, det går (til en viss grad) ut på det samme, men med HSR vil du i det minste slippe problemer hvis du snur deg fort.......

 

 

Og BTW: Det er ikke noe som heter ARB2 i OpenGL...

Det er bare noe Carmack har kalt den ene måten å rendre D3 på...

[stian-hg]

ATI og Nvidia har jukset i forskjellige størrelsesorden...

 

Uansett så vil Futuremark og 3Dmark leve videre som kongene av benchmarking!

[MistaPi]

Spill utviklerene må vel ikke bruke vendor spesifikke extensions? OpenGL ARB2 f.eks er vel en generell extension/codepath? Det er vel noe av poenget med et syntetisk benchmark, at det ikke skal være vendor sesifikke optimaliseringer som å bytte ut shader kode.

 

Må nok det desværre. Ofte man kommer borti problemer i både drivere/dx/ogl som gjør at man må kode spesifikt for hvert kort. Litt kjipt egentlig.

 

Ja greit nok, men futuremark gir ikke lov til at en IHV kan skifte ut shader kode eller at NV30/35 bruker FP16, noe som nok mange spill utviklere vil bruke pga dens svake ytelse med FP32.