Frågan om bildkvalitet är mycket mer komplicerad än att avgöra vilket grafikkort som gör en scen snabbast. För år sedan kunde vi säga att bilden som kom ut från två olika datorsystem borde vara exakt densamma eftersom utvecklare kontrollerade varje aspekt av hur deras program kördes med programvara, snarare än att överlåta vissa beslut till hårdvaran som programmet kördes på. Med tillkomsten av hårdvaruacceleration kunde utvecklare få imponerande hastighetsvinster från sin programvara. Som en bieffekt definierades implementeringen av mycket grundläggande funktionalitet helt av designerna av hårdvaran (t.ex. ATI och NVIDIA). Till exempel behöver en utvecklare inte längre oroa sig för matematiken och datavetenskapen bakom att kartlägga en perspektiv korrekt textur på en yta; Nu behöver du bara slå på de hårdvarutextureringsfunktioner som de vill ha och tilldela texturer till ytor. Förutom att rädda utvecklaren från att behöva koda den här typen av algoritmer, tog detta bort en del kontroll och gjorde det så att olika hårdvara kunde producera olika utdata (det finns mer än ett korrekt sätt att implementera varje funktion).
Uppenbarligen finns det många fler fördelar med hårdvaruacceleration än nackdelar. De hastighetsökningar som vi kan göra i 3D-rendering i realtid ursäktar alla problem som uppstår. Eftersom utvecklaren inte behöver oroa sig för att skriva kod som är värd en doktorsexamen. i matematik (som det överlåts till GPU-designerna) kan spel utvecklas snabbare eller mer tid kan läggas på innehåll. Den enda verkliga nackdelen är förlusten av kontrollen över hur allt görs.
Olika typer av hårdvara gör saker olika. Det finns mer utrymme för val i hur saker görs i 3D-hårdvara än i något som en x86-processor. För det första måste IHV:er stödja API:er (DirectX och OpenGL) snarare än en instruktionsuppsättningsarkitektur. Det finns mycket mer tvetydighet i att be en GPU att applicera en perspektiv korrekt upplyst mipmap på en yta med anisotropisk filtrering än att be en CPU att multiplicera två tal. Naturligtvis ser vi detta som en mycket bra sak. IHV:erna kommer att vara i ständig konkurrens för att ge den bästa bildkvaliteten vid den snabbaste hastigheten till det lägsta priset.
Tyvärr är det en svårare uppgift att definiera bildkvalitet än det verkar. Varken ATI eller NVIDIA producerar bilder som matchar DX9 referensrasterizern (Microsofts verktyg för att uppskatta vilken bild som ska produceras av ett program). Det finns faktiskt ingen “korrekt” bild för en given bildruta i ett spel. Detta gör det väldigt svårt att dra ett streck i sanden och säga att en GPU gör något på rätt sätt och den andra inte.
Det finns ett extra problem att ta skärmdumpar i ett spel inte riktigt är det bästa stället att börja när man letar efter en kvantitativ jämförelse. Endast en handfull tester kommer att tillåta oss att ta exakt samma ram av ett spel för användning i en direkt jämförelse. Vi ber alltid utvecklare att inkludera benchmarks i sina spel, och det här är en funktion som vi skulle älska att se i varje benchmark.
Det andra problemet med skärmdumpar är att försöka vara säkra på att bilden vi tar från framebuffern (den del av GPU:s minne som innehåller information om skärmen) är densamma som bilden vi ser på skärmen. NVIDIA sparar till exempel en del filtrering och efterbearbetning (arbete utfört på 2D-bilden som produceras från 3D-scenen) tills data skickas ut från rambufferten till visningsenheten. Detta innebär att data i framebuffern aldrig är vad vi ser på våra monitorer. För att göra det så att folk kan ta exakta skärmdumpar av sina spel, gör NVIDIA samma efterbehandlingseffekter på framebufferdata när en skärmdump tas. Även om efterbearbetning av skärmdumpar är nödvändig för tillfället, introducerar denna metod en annan oönskad variabel i ekvationen. För detta ändamål arbetar vi mycket hårt på att hitta alternativa sätt att jämföra bildkvalitet (som att ta bilder från DVI-porten).
När du försöker rendera scener är det mycket viktigt att minimera mängden värdelöst arbete en GPU gör. Detta har lett till att ett stort antal optimeringar har implementerats i hårdvara som försöker göra mindre arbete när det är möjligt. Att implementera sådana optimeringar är absolut nödvändigt för att spel ska fungera smidigt. Problemet är att vissa optimeringar gör en liten skillnad i hur en scen renderas (som att approximera saker som sinus och invers kvadratrot med numeriska metoder snarare än att beräkna det exakta svaret). Uppfattbarheten (eller avsaknaden av sådan) av optimeringen bör vara en viktig faktor i vilka optimeringar som används och vilka som inte gör det. Stort spelrum tillåts i hur saker och ting görs. För att förstå vad som händer kommer vi att försöka förklara några av grunderna för 3D-rendering i realtid.
