Futuremark, Nvidia krangler om 3DMark03

[kommers]

Jeg må si meg enig med Xell, her.

 

Føler at Futuremark burde tatt på seg tenkehatten og utviklet noe bedre enn nåværende 3DMark. For å gjøre testene mer pålitelig burde de inneholde en varierende faktor som gjør nettopp slike spesifikke optimaliseringer "umulige".

 

Til dere som maser om at "Nei, det MÅ være en fast test, ellers kan man ikke sammenligne resultatene", så burde det være mulig av Futuremark å utvikle en løsning på dette. Dagens 3DMarks benchmark-filosofi er gammeldags. Her kreves radikal nytekning av Futuremark fremfor bruke tid på å definere juksing, ulovlige overtramp og legge teoretiske optimaliseringsgrenser for driverprodusentene.

 

Selvfølgelig må det være lov å gjøre spesifikke optimaliseringer i skjermkort-driverne, dersom man klarer det uten at det går på bekostning av bildet. Skjermkortets oppgave å jo å generere et best mulig bilde med tanke på hastighet og kvalitet. Hvordan man kommer fram til "svaret" er uvesentlig, så lenge det leverer det det skal. Et benchmark-program skal anslå ytelsen til systemet for et ganske bredt spekter av mulige situasjoner systemet vil komme opp i gjennom ellers vanlig bruk av systemet. For at resultatet på benchmarken skal bli troverdig (det er her filosofien til Futuremark i dag stinker) må det være umulig å vite hvordan resultatet skal være. Dersom en variabel faktor implementeres, som det blir tatt høyde for når man beregner selve poengsummen, vil det bli en mer korrekt benchmark uavhengig av optimaliseringer.

 

For å ta en banal sammenligning for å forklare hva jeg mener:

Tenk deg at du ønsker å måle ytelsen til noen friidrettsløpere (anta her at løperne ikke blir mer slitne av å løpe langt). Det nytter da ikke å bruke den samme løypa i litt variert terreng (litt skog, åpent slettelandskap, og noen km med asfalt i byen til slutt, men like store deler at alt), si "klar, ferdig, gå!", starte klokka på startstreken og måle tida ved målstreken og gi en vurdering utifra dette. Det viser seg nemlig at løperne er veldig godt kjent i området der løypa er lagt opp og vet hvordan de kan ta noen snarveier. Dermed sparer de tid, og blir vurdert som kanskje bedre enn de egentlig er. Å bruke tiden som brukes alene som grunnlag for evnene til løperen åpner dermed for en stor feilmargin.

I stedet finner arrangørene ut at når løperne skal testes, lager de en ny og ukjent løype hver gang. Dermed blir det vanskeligere for løperen å finne snarveier (greit, han kan jo alltid løpe innersvingene for å spare tid, men det kan de jo alle/alltid hvis de vil). Denne nye løypa har også variabel lengde (fortsatt like store andeler skog, slette og asfalt), noen ganger er den kort, andre ganger er den lang. Hver løper får dermed sin unike løype. Arrangørene måler tiden fra start til mål, men deretter deler de tiden på antall kilometer på løypa. Dermed finner dem gjennomsnittsfarten til løperen, et annet mål på hvor god løperen er. Og siden løypa er ukjent for løperen hver gang kan de ikke ta store snarveier.

 

Alt handler om å skaffe seg noen bedre matematiske formler/prinsipper for å beregne ytelse.

[Martin Lie]

[-GoMp-]: Jeg kan ingenting om innmaten i verken Halo eller 3DMark03, men jeg kan gi deg en teoretisk forklaring. Som tidligere nevnt i denne tråden bruker ulike spill ulike 3d-motorer (engines). Hver motor har sine egne egenskaper, med sine egne måter å rendre bilder på. Dette kan sammenlignes med at ulike programmerere gjerne har sin egen stil over programmene de lager.

 

Hvis man så kjenner til hvordan én motor pleier å generere "3d-kode", altså man finner ut hvilke mønstre som opptrer ofte, så kan man legge inn en generell optimisering som vil føre til økt ytelse når det bestemte mønsteret opptrer ofte. Legg merke til at dette baserer seg på å forbedre rutinene uten å gjenkjenne at det faktisk er Halo (eller whatever) som kjører. Dette blir altså en indirekte og helt "all right" måte å øke ytelsen på, i motsetning til den direkte gjenkjenningen og fasit-svarene som kan ha opptrådt i 3DMark-optimaliseringene.

 

Skjermkort-produsenter jobber ofte sammen med spillutviklere, og da spesielt utviklerne av de mest populære spillene, for å få rede på slike mønstre, og dermed indirekte kunne øke ytelsen i spillet. Dette må imidlertid gjøres pr. spill, og det er ikke usannsynlig at de nyeste ForceWare-driverne har lagt inn optimiseringer som øker ytelsen for de typiske Halo-mønstrene.

 

3DMark03 derimot, har ingen 3d-motor. Det er ikke et fullverdig spill som skal generere 3d-bilder ut i fra hva spillerne gjør. Det er helt motsatt - nemlig en forhåndsdefinert rekke med skjermbilder, med tilhørende kode som skal generere disse skjermbildene. Det er derfor, slik jeg forstår det, ikke mulig å lage generelle optimiseringer for "mønstre som opptrer ofte i 3DMark" uten samtidig å jukse.

 

Hvorfor? Fordi det kun finnes ETT mønster i 3DMark - ikke flere. Det finnes kun én rekkefølge som kommandoene kommer i. Kun én eksamens-oppgave, med kun én fasit. Og enhver optimisering for denne oppgaven må da basere seg på nøyaktig gjenkjenning av nettopp rekkefølgen kommandoene kommer i. "Optimiseringene" er da kun laget for å fremstille sitt eget produkt i et bedre lys, og vil ikke vises noe annet sted enn i en bestemt 3DMark-versjon. På denne bakgrunnen har det blitt vanlig blant hardware-sider, benchmark-programmerere, spill-entusiaster, o.l. å se på slike "optimiseringer" som juks.

 

Vi står da igjen med en grei måte å forklare økt ytelse i Halo på. Optimiseringene som er gjort her skjer hele tiden, og hver dag jobber mangfoldige folk med nettopp slik mønster-gjenkjenning og generell ytelsesforbedring.

 

Men vi har ingen god måte å forklare ytelses-fallet i 3DMark build 340 på. De to teoriene vi har er:

 

1) nVidia har jukset ved å tilegne seg urettmessig høye scores i 3DMark03 330 uten at disse resultatene kan reproduseres noe som helst annet sted. De mest markante tilhengerne av denne teorien inkluderer de fleste hardware-sider, forstå-seg-påere, ATI-fanboys, osv...

 

2) Futuremark har med vilje disablet Unified Compiler. Futuremark sier at dette ikke er teknisk mulig, da det har med hvordan innmaten av nVidia-kortet tolker og setter sammen kommandoene som det får fra DirectX. De mest markante tilhengerne av denne teorien inkluderer nVidia (som lager chipen), Gainward (som selger kort basert på chipen) og nVidia-fanboys...

 

Mitt spørsmål er da:

 

Kan noen gi meg en teoretisk forklaring på hvordan 3DMark 2003 skal klare å disable en feature i nVidia-drivere/kort (Unified Compiler), så lenge 3DMark kun forholder seg til DirectX-API-et (altså kun utfører DX-funksjoner, som er helt uavhengige av hvilket skjermkort som tilfeldigvis utfører kommandoene)?

 

Inntil noen sannsynliggjør det, regner jeg det for å være mye større sjanse for at ytelsestapet nVidia-kort har i 3DMark build 340 kommer fra avslørt juks, og ikke av et nVidia-fiendtlig Futuremark.

[Martin Lie]

kommers: Hovedsaken i diskusjonen her er å få frem at nVidia har jukset. Jeg kan være enig med deg i at man bør tenke annerledes, slik at det ikke er mulig å jukse, men det endrer fremdeles ikke på dette: Alt tyder på at nVidia har jukset, og det er ikke akseptabelt.

 

Når det er sagt, så vil jeg si at jeg forstår jeg tankegangen din, og poenget ditt. Det er en god idé, og er nok det samme som tyldum tenkte på tidligere i tråden (side 1). Men jeg tror ikke dere har tenkt godt nok gjennom hva dere sier. La meg prøve å forklare:

 

1) Dere sier at vi må legge inn en variabel, slik at det blir forskjeller hver gang. Problemet her er at variabelen ikke kan legges inn i formlene, for det er jo nettopp formlene nVidia hopper over, siden de likevel vet svaret. Hvis kun formlene endres, men det endelige bildet alltid er det samme, så vil jo nVidia fremdeles vite fasiten, og kan lett jukse.

 

2) Dette betyr at det er skjermbildene som må endres. nVidia kan detektere 3DMark når som helst, for å ta noen eksempler: Både ved oppstart (splash-screen), brukergrensesnittet (der du velger hvilke detaljer du skal ta av og på), under benchmarks, og mellom benchmarks (bildet som vises mellom to benchmarks). Faktisk har det tidligere blitt rapportert at det var nettopp splash-screenen som førte til gjenkjennelse av 3DMark tidligere. Finner ikke linken til dette nå, men jeg har lest det, og har ikke problemer med å tro at det er mulig.

 

3) Skjermbildene for alt det ovennevnte må altså genereres tilfeldig hver gang 3DMark kjøres. Dere kan jo begynne å tenke på hvor vanskelig det er å generere et tilfeldig "kontrollpanel", uten at funksjonaliteten drukner.

 

4) Selv om skjermbildene under benchmarking skal være tilfeldige (altså variable), så må de likevel være gjenkjennelige, ikke sant? Men hva er det da som hindrer nVidia å lage sin egen versjon av hele tilfeldighets-prosessen? Kan ikke de bare rendre en video-snutt som er i nærheten av det som ellers ville blitt generert. Når skjermbildene har et visst element av varians, så er det jo ingen som kan si forskjellen mellom nVidia sitt "tilfeldig-bilde" og 3DMark sitt "tilfeldig-bilde". Har dere en løsning på dette?

 

 

En annen kjip ting med å legge inn tilfeldigheter i skjermbildene, er at man ikke lenger vil ha mulighet til å sammenligne bildekvalitet (IQ) mellom forskjellige skjermkort, siden det er umulig å få generert nøyaktig det samme skjermbildet to ganger.

 

Nei, jeg sier det igjen: Man må kunne forvente at skjermkort-produsenter ikke jukser. Skulle jaggu tatt seg ut om en snekker bygget et hus som så helt likt ut som naboens, og var beregnet å stå 200 år, men i realiteten viste seg å falle sammen etter 2 år. Og når du prøvde å klage til snekkeren, så ville han bare påstå at det var din feil at du gjorde det mulig for ham å lage hus som så bedre ut enn det egentlig var, og at du burde tenkt bedre gjennom det før du planla huset i det hele tatt. Makan!

 

Edit1: Typo... Kan jo ikke bryte tradisjonen nå.

 

Edit2: Og her er forresten linken til det jeg sa om splash-screen i punkt 2, over:

http://www.extremetech.com/article2/0,3973,1151521,00.asp

"...when 3DMark's initial splash screen loads, the DetonatorFX driver detects this operation and does not execute back-buffer commands issued by 3DMark03."

 

(Og hvis noen har lest alle innleggene mine, uten å hoppe, så skal de få premie!)

Endret 14. november 2003 av Pureblade

[MistaPi]

' date='13/11/2003 : 20:27'] Men en ting noen kan få lov til å forklare for meg, er hvordan de nyeste ForceWare driverne til nVidia da jobber bedre med PS2.0 i Halo, men værre med PS2.0 i 3DMark03?

Mener da at Halo fikk bedre ytelse med de nye driverne(ifølge div.tester), antakeligvis pga "Unified Complier"...Men hvorfor klarer den å jobber raskere med PS2.0 i Halo - uten tap av bildekvalitet, mens i 3DMark03, med sin nye patch, så synker ytelsen?

*spent*

Tydeligvis er det snakk om shader replacement i 3dmark03 (og sikkert andre applikasjoner) som ikke gjør det til en sann "unified compiler". Hva som skjer i Halo vet jeg ikke, men bruken av PS2.0 der er vel heller begrenset og man kan forsåvidt diskutere om man skal kalle det et "DX9 spill".

[kommers]

Pureblade, jeg skjønner hva du mener med de 4 punktene dine.

 

En del av dem kan unngås ved å gjøre følgende:

Tenk deg at en test i benchmarken er å rendre en viss scene. Scenen inneholder en kule. Størrelsen på denne kula angis av en variabel parameter, slik at for hver individuelle test vil bildet opptre noe annerledes (så driveren vet ikke det eksakte svaret på forhånd) uten at hele scenen virker annerledes på skjermen. Ved å bruke flere slike parametre, som varierer fra gang til gang, såfremt man (futuremark) kommer fram til et system/formel for å kompensere for ulemper/fordeler forskjellige verdier på parametrene gir (det er jo dette som blir vanskelig å finne en rettferdig kompensasjon), blir det vanskeligere å jukse. Jo flere variabler i benchmarken, desto bedre.

 

Alternativt kan man i mye mindre grad la være å kompensere for de varianser som opptrer. Da dukker problemet med å sammenligne andre kort opp. Det man da kunne var å fått generert et sett med tilfeldige parametre (en fil, noe à la en demo i f.eks et spill, men ikke like fullt i så stor skala, litt mindre dynamisk) som kan gis som input ved en test, slik at forskjellige kort kan benytte samme tilfeldige input når man ønsker å sammenligne verdier. Med dette systemet vil en benchmark-score bli delvis relativ totalt sett, avhengig av parametre/innstillinger, men siden alle test-systemene som skal vurderes opp mot hverandre bruker samme variabler kan man allikevel sammenligne systemene. Faren og ulempen med dette er at det blir som i spill-benchmarking, at visse demo-filer blir vanlige å bruke blant i alle benchmark-miljøer, og driverprodusenten kan spekulere i å tilpasse driveren til akkurat disse. Derfor må man generere nye parametre til hver head-to-head-test av systemer. Et slikt system vil kanskje kreve en mer fullverdig 3d-engine enn i dag. Men hvis det blir for likt spill-bench'ing, så kan man jo spørre seg hvorfor ikke dermed kun teste i et spill fremfor et eget benchmark-prog? Vitsen blir kanskje litt borte... vanskelig å si uten å vite hvor godt resultatet kan bli.

[Martin Lie]

Tenk deg at en test i benchmarken er å rendre en viss scene. Scenen inneholder en kule. Størrelsen på denne kula angis av en variabel parameter, slik at for hver individuelle test vil bildet opptre noe annerledes (så driveren vet ikke det eksakte svaret på forhånd) uten at hele scenen virker annerledes på skjermen.

Hva er det som hindrer nVidia-driveren i å velge sin egen kule-størrelse, og gi blaffen i hva 3DMark instruerer?

 

Når driveren ikke vet svaret på forhånd, så vet heller ikke jeg svaret på forhånd, og jeg aner ikke om kulestørrelsen som vises på skjermen er valgt av nVidia (og rendret på en ekstremt optimisert måte) eller 3DMark. Ergo: nVidia kan gjøre som de vil, og ingen vil kunne merke forskjell.

 

(Det var for øvrig dette jeg prøvde å si i punkt 4, over...)

[ØysteinI]

For at en benchmark skal være gyldig må det være hevet over enhver tvil at ALLE produktene som testes, blir testet på nøyaktig samme måte. I motsatt fall vil jo den tapende produsenten whine og syte og klage på at de måtte gjøre et arbeid som var tyngre enn vinneren og at testen dermed ikke var rettferdig. Og hvordan kan vi stole på en test som det kan draes inn tvil om hvorvidt testen var rettferdig eller ikke?

 

Eneste måten vi kan lage en test som er rettferdig for alle parter, er at alle må gjøre det samme stykke arbeidet med det samme resultatet. Det er også derfor at ved en test av skjermkort, så beholdes hovedkort/ram/CPU osv, samt at det mellom hver test blir lagt inn et identisk oppsett av drivere, OS osv.

 

Men når vi må kjøre en test hvor alle parter kjenner resultatet vil vi få de problemene vi står ovenfor idag. Den eneste mulige løsningen jeg kan se, er at Futuremark validerer hvorvidt nye drivere er gyldige før de benyttes i tester. F.eks kan Futuremark ha en del utgaver av 3Dmark hvor de har endret instruksjonsrekkefølgen. Disse utgavene må da ikke røpes ut til verden, da produsenter vil få en mulighet til å jukse også i disse. Hvis så Futuremark finner ut at resultatet av alle versjonene er lik, må evt. optimaliseringer i driveren fungere på et generelt grunnlag og dermed være gyldig. Plutselige hopp i ytelsen i noen utgaver av testen kan da indikere at en produsent har forsøkt seg med noe muffens.

 

Når det gjelder generelle optimaliseringer, så ser jeg at det har vært en del dårlige eksempler i denne tråden. Skal derfor prøve å komme med et litt bedre eksempel/forklaring.

Hvis 3Dmark gir instruksjonen x = 2*2*2*2*2 vil det være matematisk korrekt og lovlig å skrive en rutine i driveren som konsekvent bytter ut dette med 2^5 hvis dette er mer hensiktsmessig på den arkitekturen. Den lovlige rutinen vil da se ut som :

Hvis instruksjon = ( x = y*y*y*y*....*y) 
then instruksjon = ( x = y^(antall y'er) )
....

Denne rutinen vil da fungere på et generelt grunnlag og gavne alle situasjoner hvor dette forekommer, ikke bare en konkret applikasjon. Den er også matematisk ekvivalent med den orginale og vil dermed lage det nøyaktig resultatet. Dette med matematisk ekvivalens er veldig viktig, da dette er eneste måten man kan være helt sikker på at resultatet også blir det samme.

 

Optimaliseringer som retter seg inn mot en konkret 3D-motor er også lovlig, da dette vil gavne alle spill som bruker den samme 3D-motoren. F.eks vil alle spill som bruker Q3-motoren få glede av optimaliseringer mot Q3.

 

[EDIT] : fikset bedre kode-eksempel.

 

 

(Og hvis noen har lest alle innleggene mine, uten å hoppe, så skal de få premie!)

Kan jeg få premie nå? *grin*

Endret 14. november 2003 av ufo

[Tjohei]

Hvis 3Dmark gir instruksjonen x = 2*2*2*2*2 vil det være matematisk korrekt og lovlig å skrive en rutine i driveren som konsekvent bytter ut dette med 2^5 hvis dette er mer hensiktsmessig på den arkitekturen. Den lovlige rutinen vil da se ut som :

Hvis instruksjon = ( x = y*y*y*y*....*y) 
then instruksjon = ( x = y^(antall y'er) )
....

Enig i det. Den koden som ikke er tillatt er:

 

hvis 3dmark03:
 x = 32
ellers:
 x = 2^5

[Martin Lie]

Futuremark har kommet med ny uttalelse:

http://www.theinquirer.net/?article=12673

 

Der sier de blant annet: "If someone wants to know what is the performance on a specific game with specific drivers, 3DMark03 is not the tool to use. In that case, the user should use that specific application with those drivers."

 

*grin*

 

(Og hvis noen har lest alle innleggene mine, uten å hoppe, så skal de få premie!)

Kan jeg få premie nå? *grin*

Eh... Jada. Øhm... Du kan få 4 utdaterte RAM-brikker hvis du forklarer meg hvordan jeg attacher dem til en forum-post.

[ØysteinI]

Eh... Jada. Øhm... Du kan få 4 utdaterte RAM-brikker hvis du forklarer meg hvordan jeg attacher dem til en forum-post.

Elementært ... bare legg dem på scanner'n og scan dem inn ... så bruker du [img...]-taggen og trykk på "Svar"

[MistaPi]

ATI kommenterer saken:

 

 

It's been claimed that Futuremark's changes have disabled compilers. This is complete nonsense. ATI has had a compiler since CATALYST 3.6 and it didn't have any problems with Futuremark's changes. Shader replacement and compilers are completely different operations.

 

ATI has had a compiler since CATALYST 3.6. We didn't have any problems with Futuremark's changes. The new build of 3DMark03 gives an honest picture of the relative DX9 game performance of graphics cards. It accurately reflects what gamers will see with titles such as Half-Life 2, and what they already see with today's DX9 games, such as Tomb Raider: Angel of Darkness.

 

Secondly, it is disingenuous to claim that Shader replacement better reflects the performance in games. Only a tiny fraction of games get the attention that 3DMark03 has had from our competitors. It requires too much programming time. Over 300 PC games are launched a year, and 100 of these will really tax the graphics hardware. Maybe a half-dozen - the ones most used as benchmarks - will receive the gentle caress of the driver engineer. An honest run of 3DMark03 will give a true indication of performance for the overwhelming majority of DirectX 9 games. Gamers need to be able to play any game they want; they don't want to be locked into the six that have had all their shaders replaced.

 

Even assuming that you somehow found the resources to replace all the shaders in every game, it's still not a practical solution. Shader replacement is a massive step back for reliability and game compatibility. Every year you'll be writing thousands of Shader programs that each have to be checked for image quality, taken through QA and supported. And changed whenever the developer issues a patch. Treating every game as a special case is a huge stability issue. Developers have come out against Shader replacement. John Carmack is on record as saying "Rewriting shaders behind an application's back in a way that changes the output under non-controlled circumstances is absolutely, positively wrong and indefensible." The opinions of Gabe Newell, Valve Software's CEO, on Shader replacement are well-known. Developers hate it. What if they release a new level, the gamer downloads it and performance sucks? The hardware vendor isn't going to get any grief, because all the user sees is the old levels working fine and the new one running like molasses in January. The problem's obviously with the game, right? Developers are worried about the support nightmare this approach will generate and the damage to their own brand when they get blamed.

 

Chris Evenden

PR Director

ATI Technologies

[Martin Lie]

...og forresten så har nVidia trukket tilbake uttalelsene sine om at Unified Compiler ble slått av:

 

http://www.xbitlabs.com/news/video/display...1114041519.html

 

Det stiller jo Gainward i en litt pinlig situasjon da...

[ØysteinI]

...og forresten så har nVidia trukket tilbake uttalelsene sine om at Unified Compiler ble slått av:

 

http://www.xbitlabs.com/news/video/display...1114041519.html

 

Det stiller jo Gainward i en litt pinlig situasjon da...

Sånn går det når man har litt for kreativ omgang med sannheten. Jajaja ... da forsvant Gainward som potensiell leverandør av grafikk-kort til meg. Skal de juge og snakke piss, så kan de beholde skjermkortene sine for seg selv.

[[-GoMp-]]

Hmm...lurer på hva av dette som er sant jeg...viser seg vel med tiden

[Boralis]

Helt greit at driverne blir optimalisert, det som er problemet er at enkelte drivere blir optimalisert kun for 3d mark og det er vel neppe noen som kjøper et kort kun for 3d mark. Men det er mange som ser at kortene kommer veldig godt ut i en slik test og derfor kjøper de det, disse kundene er dermed blitt lurt av kortprodusenten.

[FJERNET111]

Helt greit at driverne blir optimalisert, det som er problemet er at enkelte drivere blir optimalisert kun for 3d mark og det er vel neppe noen som kjøper et kort kun for 3d mark. Men det er mange som ser at kortene kommer veldig godt ut i en slik test og derfor kjøper de det, disse kundene er dermed blitt lurt av kortprodusenten.

I tillegg til at det er _fåtall_ av spill som blir optimalisert og det er derfor viktig at 3dmark03 holdes så nøytralt som mulig hvis det skal ha noe for seg.

[Dipso]

Den enkleste løsningen hadde vell vært om benchmarkingsites utviklet egne benchmarks som nvidia, eller andre for den saks skyld ikke fikk kloa i.

 

Det er jo dette noen av dem har begynnt å gjøre, blant annet plukke ut spill som er delvis ukjente og bruke MANGE spill i sine roundups. Da blir det mye vanskeligere å lure seg unna med spesifike optimiseringer, da MÅ man optimisere på en sånn måte at alle/flest spill/engines tjener på det.

 

Hvis bare test mengden er stor og variert fra testsiden sin side, så ender man jo opp med et ganske pålitelig resultat. :-)