Den lille nVidia Fermi tråden: GTX 470/480/580 etc. Fermi for f...

[Greddi]

Erm, forsinkelse? gpu/cpu opererer med sykler på nanosekunder... altså 10^-9 sekunder.

 

SLI/Crossfire broen er der for å synkronisere timing og rekkefølge på visning av bildene, ikke for å dele på data. gpu'ne jobber hver for seg alene, og lager sine bilder av seg selv. GPU B hjelper ikke GPU A med å lage bildet dobbelt så fort. Istedenfor lager den sin egen bilde som kommer etterpå som bilde nr 2 etter GPU A har vist bilde nr 1. i AFR vel å merke.

 

Ved sakse metoden hvor gpu A tar en del av bilde f.eks topdelen og gpu B tar bunndelen, så fungere det akkurat det samme. Bare at gpu'ne har mindre bilde å rendre men kan rendre dem teoretisk dobbelt så fort.

 

Konklusjonen er at GPU B hjelper ikke GPU A med å dra en stor last slik at lasten reiser i en dobbelt så stor hastighet. GPU B tar den neste store lasten nr2 parallellt med GPU A.

[Theo343]

Er enig i at analogien var forhastet .

[MistaPi]

Erm, forsinkelse? gpu/cpu opererer med sykler på nanosekunder... altså 10^-9 sekunder.

Erm, ja. Jeg sier at hvis dataene for et frame skjermkortet skal begynne å jobbe på ikke ligger klart i minne og må lastest opp fra system minne eller enda verre harddisken er man uansett screwed om man har 1 GPU eller 4.

 

SLI/Crossfire broen er der for å synkronisere timing og rekkefølge på visning av bildene, ikke for å dele på data. gpu'ne jobber hver for seg alene, og lager sine bilder av seg selv. GPU B hjelper ikke GPU A med å lage bildet dobbelt så fort. Istedenfor lager den sin egen bilde som kommer etterpå som bilde nr 2 etter GPU A har vist bilde nr 1. i AFR vel å merke.

 

Ved sakse metoden hvor gpu A tar en del av bilde f.eks topdelen og gpu B tar bunndelen, så fungere det akkurat det samme. Bare at gpu'ne har mindre bilde å rendre men kan rendre dem teoretisk dobbelt så fort.

 

Konklusjonen er at GPU B hjelper ikke GPU A med å dra en stor last slik at lasten reiser i en dobbelt så stor hastighet. GPU B tar den neste store lasten nr2 parallellt med GPU A.

Ja jeg er klar over dette. Jeg mener bare at forklaringen for at hver GPU jobber med hvert sitt minne og sett med data er enklere og det er at det ikke er nok båndbredde å ha et delt minne pool for GPU'ene.

Endret 3. mars 2011 av MistaPi

[Greddi]

Erm, forsinkelse? gpu/cpu opererer med sykler på nanosekunder... altså 10^-9 sekunder.

Erm, ja. Jeg sier at hvis dataene for et frame skjermkortet skal begynne å jobbe på ikke ligger klart i minne og må lastest opp fra system minne eller enda verre harddisken er man uansett screwed om man har 1 GPU eller 4.

 

 

SLI/Crossfire broen er der for å synkronisere timing og rekkefølge på visning av bildene, ikke for å dele på data. gpu'ne jobber hver for seg alene, og lager sine bilder av seg selv. GPU B hjelper ikke GPU A med å lage bildet dobbelt så fort. Istedenfor lager den sin egen bilde som kommer etterpå som bilde nr 2 etter GPU A har vist bilde nr 1. i AFR vel å merke.

 

Ved sakse metoden hvor gpu A tar en del av bilde f.eks topdelen og gpu B tar bunndelen, så fungere det akkurat det samme. Bare at gpu'ne har mindre bilde å rendre men kan rendre dem teoretisk dobbelt så fort.

 

Konklusjonen er at GPU B hjelper ikke GPU A med å dra en stor last slik at lasten reiser i en dobbelt så stor hastighet. GPU B tar den neste store lasten nr2 parallellt med GPU A.

Ja jeg er klar over dette. Jeg mener bare at forklaringen for at hver GPU jobber med hvert sitt minne og sett med data er enklere og det er at det ikke er nok båndbredde å ha et delt minne pool for GPU'ene.

 

Det er jo det som er poenget, er at hvis texturer, bilder større enn selve minnet, så må det tas over flere sykler... "You are screwed if the data is larger then the memory and the results is lower FPS!!!!" Går vi rundt grøten eller? Og det andre minnet er ikke tilgjengelig pga den er allerede i bruk, av nettopp den andre GPU'n.

[MistaPi]

Det er jo det som er poenget, er at hvis texturer, bilder større enn selve minnet, så må det tas over flere sykler... "You are screwed if the data is larger then the memory and the results is lower FPS!!!!" Går vi rundt grøten eller? Og det andre minnet er ikke tilgjengelig pga den er allerede i bruk, av nettopp den andre GPU'n.

Jeg tror rotet ligger i at du forklarer hvorfor minnet ikke deles mellom GPU'ene når Crossfire og SLi er som det er, mens jeg forklarer hvorfor det er desginet slikt.

Man kunne nok forøvrig ha designet et dual-GPU kort med et delt minne pool, men det som hadde blitt tjent på det hadde neppe vunnet over kostnadene med å utvikle et slikt kort.

[Gjest Slettet-aabLQt]

Første score over 11k !!! *fornøyd*

 

http://3dmark.com/3dm11/759229

[efikkan]

Beklager sent svar som muligens drøyer litt langt, men her kommer det. Bare så det er sagt, det kan være at jeg har misforstått et av deres sitater her. For å unngå misforståelser så skriver jeg heretter konsekvent minnet på skjermkortet og systemminne.

 

Du forsto meg rett. Unntatt med den "1.5 GB som er kun tilgjengelig" Begge minnekretsene blir brukt. Men GPU A kan ikke låne minne fra GPU B for å lese/skrive og laste et bilde på 3 GB. siden GPU B bruker selv for å rendere et bilde som kommer etterpå.

Mulig jeg er for trøtt nå etter å ha jobbet et nattskift, men hvor er den store forskjellen på dette og om man hadde en GPU og 3GB minne som må kaste ut et 3GB stort bilde og laste opp nye teksturer for å rendre neste frame?

Jeg tror du i farten blander to ulike betydninger av begrepet "frame buffer". Følgende er helt sikkert ting som du vet, men jeg vil bare få ting avklart.

 

For det første så lagrer et spill aldri et 3GB stort "bilde" i minnet på skjermkortet selv om det hadde teoretisk fått plass. Det er driveren som styrer hvordan minnet på skjermkortet deles opp, men brukeren kan velge ulike konfigurasjoner av frame buffer og alle andre bufre. Vi har blant annet color buffer, depth buffer, stencil buffer, fbo osv. (disse går under andre navn også). F.eks. 1280x720 32bits farger med 16bits depth buffer og ingen stencil buffer vil ta opp 5,27 MB uten antialiasing, og 84,375 MB ved 16x MSAA. Den største bufferen du kan lagre på dagens skjermkort er vel 16384*16384 (tar opp 1GB), og brukes vel typisk til skygger og refleksjoner.

 

Men bare så det er sagt, å laste opp store mengder data fra systemminnet til skjermkortets minne for hvert bilde skaper store forsinkelser og det er noe som spill gjør så lite som mulig.

 

Poenget mitt er at store mengder av data som brukes under rendring ligger i GPUens minne relativt statisk (med mindre det brukes noe slikt som mega textures, kommer tilbake til den), sammen med midlertidige buffre til refleksjoner osv. og selvsagt bufferen til det som skal etter hvert bli det ferdige bildet.

 

 

For spill som streamer teksturene vil en god streaming implentasjon sørge for at teksturene er i minne før det faktisk trengs.

Jepp, slik som id techs mega texture. Denne typen teknikker kommer til å bli mye viktigere i tiden fremover siden størrelsen på innhold vokser i et mye større tempo enn størrelsen på minne på skjermkort.

 

Men det må nevnes at de fleste SM3- og SM4-klasse spill (nå snakker jeg ikke om småspill), stort sett laster opp alt i minne under lasting av et brett, om det ligger i systemminne eller minne på skjermkortet kan variere, men som regel ligger mye av statisk data i skjermkortminnet. Hvis du tenker noen år tilbake (rundt 2000 og utover) så var det veldig vanlig med at meshes (spesielt terreng) ble forbehandlet av CPU med algoritmer som "roam" og "chunked lod", og så ble det ferdig behandlede meshet sendt til GPUen for hvert bilde. I denne tiden var CPU mye kraftigere enn GPU, men det ble likevel eg ganske kraftig overhead som etter hvert førte til mindre bruk av slike algoritmer med stadig kraftigere GPUer. SM3- og SM4-spill har gjerne relativt enkle heightmaps som danner en relativt lite detaljert mesh, men så brukes det gjerne detail maps i en eller annen form, gjerne generert på direkten i form av coherent noise. Dette brukes gjerne i kombinasjon med geometry clipmaps. Spillene greier på denne måten å skape en illusjon om flere detaljer i terreng enn der faktisk er (som er greit nok), men de klarer seg med å ha brettet statisk i minne og begrenset minneforbruk.

 

For å designe mer detaljerte brett fremover, og spesielt utnytte tessellation, så vil det være behov for enorme mengder data som må flyttes inn i minnet ved behov. F.eks. Rage skal ha brett med rådata på hele 80 GB (ukomprimert), jeg vil anta at dette gjelder total størrelse inkludert alle lavere detaljnivå.

 

Om GPU'ene deler en minne pool vil ikke kravet om minne kapasitet bli større kontra 1 GPU, har man for lite minne vil man få problemer uansett.

Grunnen til at SLi/Crossfire ikke deler på minnet mellom GPU'ene (SLi/Crossfire broen har alt for lav båndbredde til dette) og har hver sin minne pool med hver sin kopi av grafikk dataene er heller pga det gir langt mer minnebåndbredde med dedikert minne og minnebuss til hver GPU.

Slik som SLI og CrossFire fungerer, så lagrer minnet på hvert av skjermkortene den samme dataen, den eneste forskjellen er egentlig det som hvert skjermkort rendrer (output altså).

 

Ved AFR vil uansett minnet på begge skjermkortene lagre det samme, men med SFR kunne det teoretisk vært mulig at hvert skjermkort kun lagret det som de selv trengte til rendring av sin del av skjermbildet. Men selv om dette hadde vært implementert ville det blitt ganske ugjennomførlig i praksis der kamera skal kunne bevege seg veldig fritt, siden maskinen ikke vil rekke å fylle opp minnet på skjermkortet med ny relevant data før neste bilde skal være ferdigrendret uten å skape såpass store forsinkelser at gevinsten av multi-GPU forsvinner.

 

Det er helt riktig at SLI-/CrossFire-bro er kun til synkronisering. Det er bare å telle pinner i forhold til 384-bits minnebuss til f.eks. GTX 580.

 

Men la oss se for oss et teoretisk skjermkort med to GPUer og delt minnebuss. Hvis SLI med SFR hadde vært implementert annenledes hadde det vært teoretisk mulig å få utnyttet minnet ganske optimalt, altså at 3GB på delt buss ville vært mye bedre enn 1,5GB for et enkelt kort. Jeg synest dette hadde vært interessant fra et teknologisk standpunkt, men jeg er spent på hvor stor forsinkelsen ville blitt på minnetrafikken.

 

<klipp>

Ved sakse metoden hvor gpu A tar en del av bilde f.eks topdelen og gpu B tar bunndelen, så fungere det akkurat det samme. Bare at gpu'ne har mindre bilde å rendre men kan rendre dem teoretisk dobbelt så fort.

 

Konklusjonen er at GPU B hjelper ikke GPU A med å dra en stor last slik at lasten reiser i en dobbelt så stor hastighet. GPU B tar den neste store lasten nr2 parallellt med GPU A.

Det stemmer, SLI fungerer veldig godt når det er stor last og lite minnebehov, mens SLI hjelper ikke på minnebehov/minneproblemer.

 

Det er jo det som er poenget, er at hvis texturer, bilder større enn selve minnet, så må det tas over flere sykler... "You are screwed if the data is larger then the memory and the results is lower FPS!!!!" Går vi rundt grøten eller? Og det andre minnet er ikke tilgjengelig pga den er allerede i bruk, av nettopp den andre GPU'n.

Litt usikker på hva du mener her. Men du kan ikke ha teksturer eller andre bufre som er på en slik størrelse, og hvis du laster ting opp i buffre under rendering, så frigjør de og laster opp mer for å fortsette rendering så vil du få en framerate som er totalt uspillbar.

[MistaPi]

Jeg tror du i farten blander to ulike betydninger av begrepet "frame buffer". Følgende er helt sikkert ting som du vet, men jeg vil bare få ting avklart.

 

For det første så lagrer et spill aldri et 3GB stort "bilde" i minnet på skjermkortet selv om det hadde teoretisk fått plass. Det er driveren som styrer hvordan minnet på skjermkortet deles opp, men brukeren kan velge ulike konfigurasjoner av frame buffer og alle andre bufre. Vi har blant annet color buffer, depth buffer, stencil buffer, fbo osv. (disse går under andre navn også). F.eks. 1280x720 32bits farger med 16bits depth buffer og ingen stencil buffer vil ta opp 5,27 MB uten antialiasing, og 84,375 MB ved 16x MSAA. Den største bufferen du kan lagre på dagens skjermkort er vel 16384*16384 (tar opp 1GB), og brukes vel typisk til skygger og refleksjoner.

Ja jeg er forsåvidt klar over det, jeg tenkte på det som en mer hypotetisk greie.

 

Uansett, takk for et bra svar.

[Theo343]

Da har jeg forstått det rett selv om det alltid er godt med en ekspert forklaring.

[Buzz76]

Åssen fordeler har nvidia 5xx serien fremfor AMD 69xx serien?

 

Jeg har valgets kvaler...

[Ourasi]

Åssen fordeler har nvidia 5xx serien fremfor AMD 69xx serien?

 

Jeg har valgets kvaler...

 

Den eneste fordelen verd å nevne er at 5xx kortene skalerer noe bedre på klokking enn HD69xx, når det gjelder fordeler HD69xx har fremfor nvidia 5xx, så er det faktisk en god del flere å ramse opp, men den får du ta i 6xxx tråden etter du har stokket litt om på spørsmålet...

 

 

Merk at dette er min mening, og en noe forkortet ned sådan...

Endret 6. mars 2011 av Ourasi

[Buzz76]

Åssen fordeler har nvidia 5xx serien fremfor AMD 69xx serien?

 

Jeg har valgets kvaler...

 

Den eneste fordelen verd å nevne er at 5xx kortene skalerer noe bedre på klokking enn HD69xx, når det gjelder fordeler HD69xx har fremfor nvidia 5xx, så er det faktisk en god del flere å ramse opp, men den får du ta i 6xxx tråden etter du har stokket litt om på spørsmålet...

 

 

Merk at dette er min mening, og en noe forkortet ned sådan...

 

Takk for svaret

Det jeg tenkte på var nok om Tesselering og PhysX har noe for seg i nvidia sin favør eller ei. Overklokking er ikke endel av vurderingen.

[RamGuy]

Åssen fordeler har nvidia 5xx serien fremfor AMD 69xx serien?

 

Jeg har valgets kvaler...

 

Den eneste fordelen verd å nevne er at 5xx kortene skalerer noe bedre på klokking enn HD69xx, når det gjelder fordeler HD69xx har fremfor nvidia 5xx, så er det faktisk en god del flere å ramse opp, men den får du ta i 6xxx tråden etter du har stokket litt om på spørsmålet...

 

 

Merk at dette er min mening, og en noe forkortet ned sådan...

 

Hmm, jeg er svært interessert i dine formeninger om GeForce 500 serie vs Radeon 6000 serie! Hvor langt er det vanlig å få klokket GTX580? Tenkte jeg skulle prøve å presse ut litt ekstra juice innen TG2011.

[Nizzen]

Gtx 580 klokker rundt om gpu 920 / mem 22xx. Det er ikkje noen fastit, men utifra resultater rundt om så kan det virke slik.

 

Mine gigabyte overklokker noe rundt om det samme.

 

 

 

 

 

[ThePainx]

Åssen fordeler har nvidia 5xx serien fremfor AMD 69xx serien?

 

Jeg har valgets kvaler...

 

Kjøp det du har lyst på eller hva "pungen" tåler du blir fornøyd med kjøpet uansett hva du går for.

[Ourasi]

@RamGuy:

 

Mitt er 100% stabilt på 900/2300, da med 1.15v satt i AB, noe svakere på core enn Nizzen og enkelte andre, men sterkere på minne, men små forskjeller når det gjelder maxklokk på luft. De fleste ender opp i 900 +/- på core og 2200 +/- på minne... Mange må nok redusere klokken sin til sommeren tipper jeg, med aircon slipper jeg å tenke på 30C temps i stua ved spilling, og kan kjøre på med "set it and forget it" prinsippet, selv om maxklokk er unødvendig og er forbeholdt benching inntil et spill skulle trenge det...

Endret 6. mars 2011 av Ourasi

[Philophobe]

Åssen fordeler har nvidia 5xx serien fremfor AMD 69xx serien?

 

Jeg har valgets kvaler...

 

Hmm skal vi se..

 

Nvidia:

+Physx

+Cuda

+Bedre i spill med tung tesselering

+Linux driver støtte

 

 

AMD

+Eyefinity (mulighet for 3+ skjermer med ett kort)

+Lavere strømforbruk (Dog er forskjellen mye mindre i spill enn ved tester med furmark)

+Bedre i spill med tung shader-bruk

 

 

Vil si det er nesten umulig å velge feil om dagen. Du får mye for pengene dine uansett hvilket kort du velger fra AMD/Nividia fra middelklassen og oppover.

 

 

 

 

 

[Heradon]

Åssen fordeler har nvidia 5xx serien fremfor AMD 69xx serien?

 

Jeg har valgets kvaler...

 

Hmm skal vi se..

 

Nvidia:

+Physx

+Cuda

+Bedre i spill med tung tesselering

+Linux driver støtte

 

 

AMD

+Eyefinity (mulighet for 3+ skjermer med ett kort)

+Lavere strømforbruk (Dog er forskjellen mye mindre i spill enn ved tester med furmark)

+Bedre i spill med tung shader-bruk

 

 

Vil si det er nesten umulig å velge feil om dagen. Du får mye for pengene dine uansett hvilket kort du velger fra AMD/Nividia fra middelklassen og oppover.

Trenger man virkelig Cuda og Physx?

[efikkan]

Det får være opp til hver enkelt å vurdere, men f.eks. Premiere bruker Cuda og noen spill benytter PhysX.

[RamGuy]

Åssen fordeler har nvidia 5xx serien fremfor AMD 69xx serien?

 

Jeg har valgets kvaler...

 

Hmm skal vi se..

 

Nvidia:

+Physx

+Cuda

+Bedre i spill med tung tesselering

+Linux driver støtte

 

 

AMD

+Eyefinity (mulighet for 3+ skjermer med ett kort)

+Lavere strømforbruk (Dog er forskjellen mye mindre i spill enn ved tester med furmark)

+Bedre i spill med tung shader-bruk

 

 

Vil si det er nesten umulig å velge feil om dagen. Du får mye for pengene dine uansett hvilket kort du velger fra AMD/Nividia fra middelklassen og oppover.

Trenger man virkelig Cuda og Physx?

 

Trenger blir jo opp til hver enkelt og vurdere. Jeg vurderer det mer dithen at det er kjekt å ha, hvorfor velge et kort som ikke har det når jeg kan velge et kort som faktisk har det? AMD og nVIDIA har mange kort, i veldige like prissegmenter som yter tilnærmet i samme baner så da må du nesten vurdere hva du foretrekker av AMD vs nVIDIA drivere, om du verdsetter Eyefinity og bedre videoakselerering eller det å ha PhysX og CUDA støtte osv osv..