Dette er årets beste produkter

[N o r e n g]

- Jeg er bare litt nysgjerrig på hvordan RadeonPro fikser adaptive Vsync, kjører det i bakgrunnen og justerer buffering fortløpende mens spillet kjører gjennom AMDs API? (Jeg jobber for tiden bare med NVAPI/NVCtrl)

- Jeg ser ikke for meg at en cap kan løse ujevnheter i forsinkelser mellom bilder.

- At Nvidia har mer funksjonalitet er det ingen tvil om, helt siden G80 har Nvidia hatt mye mer funksjonalitet. For spillere er mer avanserte AA-modi og bindless graphics mest aktuelt, hvorav sistnevnte ikke har blitt anvendt i et eneste spill så langt, på tross av det kan gi 50-100% bedre ytelse eller mer. Fermi kom med en rekke funksjonalitet for det profesjonelle markedet, og Kepler har utvidet dette med muligheter for å streame data fra PCIe-enheter direkte, shader-programmer kan starte egne instanser, osv. Kepler gir også bindless textures, som gjør at shadere får bedre ytelse og kan benytte "ubegrenset" med teksturer mot 32/128 før (igjen ingen som bruker ennå). I hele det aktuelle tidsrommet har AMD hatt enklere GPUer med langt høyere teoretisk regnekraft, men selv Southern Islands sliter med å utnytte potensialet.

- Jeg kan si meg enig i at Nvidias kontrollpaneler er mangelfulle, Windows-versjonen er bedre på profiler men mangler mange innstillinger som Linux-versjonen har

-Jeg vet ikke hvordan RadeonPro fikser "Dynamic Vsync" (som den kalles,) men det gir ikke den lett gjenkjennelige økte inputlagen man får vanligvis med Vsync aktivert i CS, og selv om framerate faller under refresh rate er det fortsatt null tearing. Det er som om den gir Triple Buffer Vsync uten noe økt forsinkelse og samtidig klarer å nå 120 fps (så trikset med framerate cap på 118-119 fps og vsync er ikke i bruk.)

-Vel, du kan sammenligne selv med resultatene jeg fikk i Dishonored med 8xSSAA (for å øke belastningen): cap, ingen cap, rimelig stor forskjell der.

-Nvidias CSAA matches av EQAA på AMD-kort, AMD-kortene har også Adaptive Anti-Aliasing som gjør en lignende jobb som Nvidias transparency AA, ellers har begge sidene støtte for SSAA. Har jeg glemt noen AA-modi? AMD kaller så vidt jeg har forstått Bindless Textures for Partially Resident Textures.

-Bra vi er enige her

 

Mener du at supertiling vil medføre mindre problemer med stutter? Jeg ser for meg store synkroniseringsproblemer og ineffektiv bruk av GPU-sykler.

 

Kan du utdype hva du mener med at det bufres et bilde ekstra? Den primære grunnen til at bilder kommer ujevnt med SLI/CrossFire er at når GPU2 er ferdig må GPU1 stoppe for å ta imot data fra GPU2 og deretter fortsette sitt halvferdige bilde. Dermed kommer bildene i et ujevnt intervall, ofte med et klart mønster der to bilder kommer tett (det første fra GPU1, det andre fra GPU2), og deretter et lengre opphold.

Supertiling vil definitivt senke GPU-bruken litt og betraktelig senke skaleringen, men det vil i det minste redusere stutter ettersom man må vente på at alle GPUene har tegnet ferdig sin del av bildet, og det vil også kutte ned på antall bufrede frames en trenger. Mener også å huske å ha lest at Quad-SLI fungerer ved at GPUene deles inn i par som gjør Supertiling med 2-veis AFR, men mulig jeg tar feil der.

 

Alternate Frame Rendering fungerer ved at man gir hver GPU en frame å jobbe med, altså må CPU jobbe to frames foran bildet på skjermen med ingen AFR, tre frames foran bildet med 2-veis AFR og fire frames foran bildet med 3-veis AFR. Den økte forsinkelsen blir motvirket av den senkede tiden per frame.

Hvis GCN skal sammenlignes mot Kepler så må det spesifiseres hvilken målgruppe det gjelder for. FP64, ECC osv. har liten relevans for spillere.

Uavhengig av hvilken som er "best", så mener jeg at Fermi var relativt sett bedre for sin tid enn det Kepler er i dag, og at selv med Fermi sine barnesykdommer så har Nvidia tabbet seg heftigere ut med GK100. Hvis du husker tilbake for et år siden da det ble kjent at GK100 hadde problemer så ble Nvidia overrasket over at Southern Islands ikke var kraftigere. 2012 kunne blitt et "katastrofeår" PR-messig for Nvidia, men siden AMD ikke gjorde mer så gikk det fint for Nvidia å lansere sin GK104 som toppmodell.

Det eneste resultatene vi har for å sammenligne arkitekturene mot hverandre er i gaming.

 

Mye av skylda til HD 7970 sin dårlige ytelse ved lansering kan også skyldes på umodne drivere/software, det er vanskelig å nekte for at HD 7000-serien har hatt noen utrolige driverforbedringer i løpet av et år. Siden vi antar at GK100 ble skrapet lenge før Tahiti kom ut er det også rimelig å anta at GK104 fikk ekstra arbeid lagt inn så den kunne komme opp på et ytelsesnivå verdig for å kalles et GTX 670, så kom HD 7970 ut og Nvidia fant ut de hadde noe de kunne kalle et GTX 680.

[N o r e n g]

Du av alle burde skjønne at for hvermansen er det mye lettere å gå inn i nativedriveren du må ha enn å laste ned et "usikkert"(sier usikkert fordi for vanlige brukere er det mange som ikke tolererer at disse tingene ikke er støttet direkte av AMD gjennom catalyst control center) tredjepartsprogram for å støtte en funksjon AMD ikke reklamerer for en gang. Nvidia derimot har nøye reklamert og forklart hvordan du bruker adaptive v-sync og viser det på nettsidene sine under geforce. mye lettere å finne informasjon og er støttet direkte gjennom driveren du må ha.

Nekter ikke for at RadeonPro er hva CCC burde være, heldigvis blir skaperen blir allerede hjulpet og støttet av AMD

 

Nevn en ting med 6000 serien som var bedre enn 500 serien? 500 serien hadde mer ytelse og bedre bang for the buck på alle nivåer(spesielt 560ti var eksepsjonell). eneste kortet som var bedre enn direkte konkurrende kort var 6990 men det støyet og slukte strøm på et slikt nivå at det ikke kunne taes seriøst. og SLI var som vanlig bedre enn CFX. Går med på at prisnivået ble veldig annerledes etter ca 6 mnd men selv da var Nvida et klart bedre valg.

Nei.

HD 6000-serien hadde lavere effektforbruk mot ytelse. Pris mot ytelse var bedre enn Nvidias alternativer, det var en kort periode da GTX 560 Ti var likt priset med det 5% svakere 6870, men det er bare å se på prisstatistikken for den mest populære 6870-varianten så ser du at dette var tilfelle fra januar til mars 2011. 6950 var priset høyere fordi det også leverte bedre ytelse enn 560 Ti, og Nvidia hadde ingenting til å svare 6850, 6770, 6750, 6670, eller 6570. Grunnen til at 560 Ti var en suksess var fordi det var et fornuftig priset kort fra Nvidia, og ikke AMD. GTX 570 matchet 6970 rimelig bra, men hadde betydelig mindre VRAM, og GTX 580 var alene på toppen.

[cannibalguppy]

Nekter ikke for at RadeonPro er hva CCC burde være, heldigvis blir skaperen blir allerede hjulpet og støttet av AMD

 

 

Nei.

HD 6000-serien hadde lavere effektforbruk mot ytelse. Pris mot ytelse var bedre enn Nvidias alternativer, det var en kort periode da GTX 560 Ti var likt priset med det 5% svakere 6870, men det er bare å se på prisstatistikken for den mest populære 6870-varianten så ser du at dette var tilfelle fra januar til mars 2011. 6950 var priset høyere fordi det også leverte bedre ytelse enn 560 Ti, og Nvidia hadde ingenting til å svare 6850, 6770, 6750, 6670, eller 6570. Grunnen til at 560 Ti var en suksess var fordi det var et fornuftig priset kort fra Nvidia, og ikke AMD. GTX 570 matchet 6970 rimelig bra, men hadde betydelig mindre VRAM, og GTX 580 var alene på toppen.

 

560ti var likt universielt. fordi det var det beste pris/ytelse kortet der ute. ikke en test av forrige generasjon anbefalte AMD over nvidia bortsett fra laveste segment. lurer på hvorfor: bedritne drivere, dårlig ytelse. 570 var faktisk en del bedre enn 6970. og SLI fungerte bra mens CFX ikke fungerte bra.

 

Du glemmer også den sinnsykt bra skaleringen på 560ti SLI.

 

var kun en grunn til å gå for AMD kort og det var pris. men dette argumentet er ikke bra nok når konkurrenter har et så mye bedre produkt.

 

Men Radeonpro er bra, skal ikke si at det ikke er det. bare dumt at CCC driveren ikke støttet alt dette for over et år siden da Nvida har gjort det i nesten et år.

Endret 6. januar 2013 av cannibalguppy

[efikkan]

-Vel, du kan sammenligne selv med resultatene jeg fikk i Dishonored med 8xSSAA (for å øke belastningen): cap, ingen cap, rimelig stor forskjell der.

Godt å se at capen er basert per frame, ikke per sekund. Legg likevel merke til hvordan denne capen påvirker "worst case". Dette er ingen god løsning på problemet.

16.67 ms begynner å bli såpass kort at det blir vanskelig for maskinen å time det perfekt, og som du ser i grafen din så kan forsøk på å fryse renderingen faktisk medføre ennå høyere "spikes". Det blir ennå verre med høyere bilderater.

 

-Nvidias CSAA matches av EQAA på AMD-kort, AMD-kortene har også Adaptive Anti-Aliasing som gjør en lignende jobb som Nvidias transparency AA, ellers har begge sidene støtte for SSAA. Har jeg glemt noen AA-modi?

Hvor høyt får du EQAA? CSAA er opptil 32x for GeForce, 128x for Quadro.

 

AMD kaller så vidt jeg har forstått Bindless Textures for Partially Resident Textures.

Nei det er ikke det samme.

 

PRT er AMDs variant av (Sparse) Virtual Textures, som igjen er det samme som IDs Megatexture, og går ut på å lagre utsnitt av en stor tekstur i en fast teksturcache, med medfølgende problemer som clipping mellom tiles(hindrer god teksturfiltrering), samt mye shaderlogikk for å kalkulere til virtuelle teksturkoordinater. AMDs PRT inneholder en OpenGL-utvidelse som hjelper med koordinatregningen for å minke ytelsetapet.

 

Bindless Graphics er en rekke utvidelser for å fjerne binds fra driver til GPU ved rendering, slik at driveren slipper å regne frem til minneadresser i GPUen og sende disse til shaderen, mens shaderen selv opererer direkte med pekere til GPU-adresser(hvis du vet hva pekere i C/C++ så forstår du prinsippet), og ved å spesifisere rekkevidden i GPU-adresser unngås store mengder cache misses. Dette har maskinvaren til Nvidia støttet siden G80, og ytelsefordelen blir større til flere objekter som skal tegnes. Kepler byr også på Bindless Textures som på tilsvarende vis aksesserer teksturer som pekere, til forskjell fra gamlemetoden ved å binde utsnitt av teksturen til faste "båser"(32 OpenGL,128 Direct3D) i L2 cache, som både er ineffektivt og tungt for driveren å regne ut. Dermed kan teksturdata blandes i shader fra et nesten ubegrenset antall teksturer og bufre, men etter 20 år på den tungvindte måten vil det nok ta tid før folk innser hva dette tillater. Jeg har sett at AMDs driverutviklere har nevnt at de vurderer å implementere støtte på sine forum, men jeg regner med at dette krever tilpassinger i maskinvaren. Jeg håper dette kommer på plass i HD 8000-serien, men jeg tviler...

 

Var det en ok forklaring?

 

Supertiling vil definitivt senke GPU-bruken litt og betraktelig senke skaleringen, men det vil i det minste redusere stutter ettersom man må vente på at alle GPUene har tegnet ferdig sin del av bildet, og det vil også kutte ned på antall bufrede frames en trenger. Mener også å huske å ha lest at Quad-SLI fungerer ved at GPUene deles inn i par som gjør Supertiling med 2-veis AFR, men mulig jeg tar feil der.

Hmm, problemene blir å balansere lasten og synkronisere tiles tilbake. Vet du hvilket stadium disse blir overført tilbake på? Jeg ser for meg at hvis rutenettet tegnes helt ferdig på hver GPU og deretter blandes så vil det skape synlige artifacts, så jeg antar at tiles må overføres før rasterizing er ferdig, som medfører at ganske store datamengder må overføres. Denne kostnaden økes med høyere AA, så dette er kanskje grunnen til at vi ikke ser det lenger? Fordelen med AFR er i det minste at bildet er kompakt og ferdig når det overføres.

 

Nå vil jeg illustrere ytelseproblemet med AFR, la oss si at et tidsintervall på 1.0 er tiden én GPU bruker på et helt bilde. Med 2 GPUer:

t=0.0 GPU1 ferdig, swapper buffer og starter på neste

t=0.5 GPU2 ferdig, driver må stoppe begge GPUer og deretter hente bildet(2-4MB), for så å sende det til GPU1.

t=0.5+x1 GPU2 starter på neste

t=0.5+x2 GPU1 fortsetter på sitt halvferdige bilde

t=1.0+x2 GPU1 ferdig, swapper buffer og starter på neste

t=1.5+x1 GPU2 ferdig .....

Poenget her er at så lenge x2 er en del større enn x1 så vil intervallet mellom bildene bli ulikt. Derfor foreslår jeg en GPU-løsning der hoved-GPUen ikke rendrer i det hele tatt, men kun tar imot bilder fra de x antall andre GPUene.

 

Siden vi antar at GK100 ble skrapet lenge før Tahiti kom ut er det også rimelig å anta at GK104 fikk ekstra arbeid lagt inn så den kunne komme opp på et ytelsesnivå verdig for å kalles et GTX 670, så kom HD 7970 ut og Nvidia fant ut de hadde noe de kunne kalle et GTX 680.

Så vidt jeg vet ble GK100 kjent skrapet tidlig i februar, trolig rundt årsskiftet. Tapeout for både GK100 og GK104 var mange måneder i forveien, og mellom disse to tidspunktene var det ingenting de kunne gjøre. Da "katastrofen" inntraff valgte nok Nvidia å presse GK104 en del lenger enn opprinnelig planlagt, som jeg tror er grunnen til at GTX 670 er langt mer balansert, mens GTX 680 er presset "litt for langt". GK104 var aldri designet for å slå Tahiti XT. Nvidia gjorde et smart triks med å bruke boost som trekte opp gjennomsnittsytelsen med cirka 5%, som var nok til å komme et hestehode fremfor HD 7970 i mange tester, uten at GTX 680 var reelt raskere. Nvidia tok virkelig vann over hodet denne gangen med alt for ambisiøse mål

[N o r e n g]

Hvor høyt får du EQAA? CSAA er opptil 32x for GeForce, 128x for Quadro.

EQAA på et 7970 går opp til 16x, det er da 16x multisampling og 32x coverage samples.

Ser ut til at jeg glemte en AA-modus: Custom-Filter AA, den kan operere på 12x eller 24x, visstnok bruker den shadere til å velge samples ut fra en sirkel rundt pikselen.

 

Hmm, problemene blir å balansere lasten og synkronisere tiles tilbake. Vet du hvilket stadium disse blir overført tilbake på? Jeg ser for meg at hvis rutenettet tegnes helt ferdig på hver GPU og deretter blandes så vil det skape synlige artifacts, så jeg antar at tiles må overføres før rasterizing er ferdig, som medfører at ganske store datamengder må overføres. Denne kostnaden økes med høyere AA, så dette er kanskje grunnen til at vi ikke ser det lenger? Fordelen med AFR er i det minste at bildet er kompakt og ferdig når det overføres.

Ifølge denne artikkelen brukte første utgave av CrossFire Supertiling som standard-modus for Direct3D, og at dette hadde ulempen at geometri måtte utregnes på alle kortene, det vil i så fall ikke ha en god effekt på MSAA-ytelse og er sikkert grunnen til at de valgte å gå over til AFR. Jeg er helt enig med deg når det kommer til at det hadde vært en bedre løsning å bruke en dedikert GPU til bufring, eneste problem må være at latency hadde økt enda mer.

 

Nå vil jeg illustrere ytelseproblemet med AFR, la oss si at et tidsintervall på 1.0 er tiden én GPU bruker på et helt bilde. Med 2 GPUer:

t=0.0 GPU1 ferdig, swapper buffer og starter på neste

t=0.5 GPU2 ferdig, driver må stoppe begge GPUer og deretter hente bildet(2-4MB), for så å sende det til GPU1.

t=0.5+x1 GPU2 starter på neste

t=0.5+x2 GPU1 fortsetter på sitt halvferdige bilde

t=1.0+x2 GPU1 ferdig, swapper buffer og starter på neste

t=1.5+x1 GPU2 ferdig .....

Poenget her er at så lenge x2 er en del større enn x1 så vil intervallet mellom bildene bli ulikt. Derfor foreslår jeg en GPU-løsning der hoved-GPUen ikke rendrer i det hele tatt, men kun tar imot bilder fra de x antall andre GPUene.

Jeg trodde CFX/SLI-broene brukes for å overskrive bildet som ligger på/mot RAMDACen? Det vil jo forklare hvorfor SLI/CFX vanligvis forverrer problemene med screen tearing noe vanvittig.

Jeg kan i hvert fall ikke forstå hvordan man kan nå såpass høy utnyttelse og skalering om synkronisering av frames ikke skjer nærmest instantant. Om løsningen hadde vært å stoppe hele systemet til GPU1 hadde begynt å arbeide igjen burde ikke problemet vært vanskelig å fikse eller noe som krevde at Kepler skulle fått dedikert maskinvare for å fikse dette.

[efikkan]

Ifølge denne artikkelen brukte første utgave av CrossFire Supertiling som standard-modus for Direct3D, og at dette hadde ulempen at geometri måtte utregnes på alle kortene, det vil i så fall ikke ha en god effekt på MSAA-ytelse og er sikkert grunnen til at de valgte å gå over til AFR. Jeg er helt enig med deg når det kommer til at det hadde vært en bedre løsning å bruke en dedikert GPU til bufring, eneste problem må være at latency hadde økt enda mer.

Nei tvert imot, latency ville blitt redusert siden overføringen ikke hadde påvirket de andre kortene som rendrer.

Jeg trodde CFX/SLI-broene brukes for å overskrive bildet som ligger på/mot RAMDACen? Det vil jo forklare hvorfor SLI/CFX vanligvis forverrer problemene med screen tearing noe vanvittig.

Jeg kan i hvert fall ikke forstå hvordan man kan nå såpass høy utnyttelse og skalering om synkronisering av frames ikke skjer nærmest instantant. Om løsningen hadde vært å stoppe hele systemet til GPU1 hadde begynt å arbeide igjen burde ikke problemet vært vanskelig å fikse eller noe som krevde at Kepler skulle fått dedikert maskinvare for å fikse dette.

SLI-/CrossFire-broene er kun til synkronisering, all annen data går over PCIe-bussen.

[N o r e n g]

Nei tvert imot, latency ville blitt redusert siden overføringen ikke hadde påvirket de andre kortene som rendrer.

 

SLI-/CrossFire-broene er kun til synkronisering, all annen data går over PCIe-bussen.

Jeg tenkte på at en dedikert GPU til bufring/synkronisering vil legge til enda et steg, og av den grunn vil øke latency.

 

Ifølge Nvidias Geforce-sider (i den grad de kan stoles på) brukes broen til "synchronization, display, and pixel data," med 1GB/s båndbredde burde det definitivt være mer enn synkroniseringen broen brukes til.