Gå til innhold

Test: Nvidia Gefore GTX 480


Anbefalte innlegg

Videoannonse
Annonse

Fatter egentlig ikke hvorfor man på død og liv må kjøre spillfysikk på GPU? Dagens quad CPU'er har som regel 50-70% av ressursene sine ledige selv i de mest krevende spill.

 

Å designe et "CUDA"-kort og selge som et skjermkort er også ganske latterlig spør du meg. Mye bedre om de hadde designet et "rent" spillkort (som ATI har gjort) og heller laget et eget kort for HPC-markedet. Det ryktes at ATI jobber med nettop dette (skal se om jeg finner igjen kildene).

Lenke til kommentar

Vel etter det jeg vet så er ikke ATI kort bygget for å klare PhysX (CUDA) prossesering.

Hva er det egentlig du vet? For etter min viten er du så langt ut på jordet som man kan komme her. "bygget for å klare"? Man er nesten fristet til å bruke noen freske uttrykk fra Texas.

 

Eneste årsaken til at ATi ikke støtter PhysX offisielt er fordi de ikke ønsket å implementere støtte for CUDA i sine drivere som PhysX baserer seg på.

 

Dette ønsket uavhengige 3. parter å gjøre noe med for godt og vel et år tid siden, så de la inn støtte for CUDA i ATi sine drivere og kjørte PhysX som en demostrasjon. Dette var ikke for å gi ATi kjøpere støtte for PhysX men for å vise at det helt greit lot seg gjøre og for å presse AMD til å endre beslutningen om å ikke støtte CUDA.

 

Hvorfor i ALLE dager skulle ikke ATi sine kort kunne kjøre PhysX?! Man hører mye hinsides her på forumet!

 

Når det gjelder de driverne er de så dårlige at det det må vøre en spøk at de nevnes.

La meg gjette vilt på at du ikke visste noe som helst om at dette initiativet og at dette bare er mer svada type bla bla.

 

PhysX koding i seg selv blir nok bare mer og mer optimalisert mot nVidia arkitektur men det hadde ikke vært noe som helst i veien for å kjøre det på ATi heller.

 

 

GDI:

AMD har sagt til oss at Brook+/CAL (regner med at det er det du mener) er "dødt". De kommer til å satse på OpenCL og DirectCompute. Dette løser dessverre ikke problemene, da du allikevel må skrive bortimot dedikert kode for forskjellige arkitekturer.

Dette kan du bedre enn de fleste av oss på forumet, men jeg leste nå litt tilbake (6mnd?) at Streams 2.0, spesielt på HD5xxx, skulle gi et vesentlig ytelsesløft og ble vel demonstrert bla. i noen CS sammenhenger?

 

OpenCL og DC ( takk for påminnelsen ) er nok satsningsområdet videre ja, men som du sier fjerner ikke det alle arkitekturforskjeller, men har vi noe lag som egentlig gjør det? Eller kan man si at vi da nærmer oss en god felles grunn.

Endret av Theo343
Lenke til kommentar

Det er nok teknisk sett mulig å implementere CUDA på ATI sine GPUer, men sannsynligheten er stor for at det er små detaljer som hindrer det i å få god ytelse, CUDA er som kjent optimalisert for nVidia sin arkitektur som er litt forskjellig fra ATI sin.

 

nVidia må vel ta et valg snart, om de enten vil få PhysX over på OpenCL (og eventuelt DirectCompute) eller om det skal fortsette som nVidia-eksklusivt. Konsekvensen av førstnevnte er at nVidia vil miste sitt "konkurransefortrinn" (og må da fokusere på å være suverene på OpenCL, noe som de forøvrig er gode på), konsekvensen av det andre alternativet er at PhysX ikke vil bli utbredt og alternativer etter hvert vil overta.

Lenke til kommentar

Fatter egentlig ikke hvorfor man på død og liv må kjøre spillfysikk på GPU? Dagens quad CPU'er har som regel 50-70% av ressursene sine ledige selv i de mest krevende spill.

Fordi selv ikke dagens råeste CPU'er hadde maktet det nivået av fysikk som GPU klarer. Enkel spillfysikk kjører idag på CPU, og PhysX for eksempel har også en CPU implementasjon, og selvsagt også en XBox360 og PS3 implementasjon.

 

Å designe et "CUDA"-kort og selge som et skjermkort er også ganske latterlig spør du meg. Mye bedre om de hadde designet et "rent" spillkort (som ATI har gjort) og heller laget et eget kort for HPC-markedet. Det ryktes at ATI jobber med nettop dette (skal se om jeg finner igjen kildene).

Foreløpig er det ikke penger nok i HPC-markedet til at det lønner seg å lage egne dedikerte brikker. Det trengs heller ikke. AMD sine kort er overhodet ikke noe "rene" spillekort det er krav om GPGPU for DX11 (DirectCompute) og OpenCL/OpenGL. Eneste forskjellen er måten ting implementeres på. AMD bruker også samme arkitektur som de gjorde i 2007. Foreløpig er ryktene at neste GPU "Northern Islands" (RV9x0) blir en ny arkitektur. Denne kommer nok til å implementere mye av hva vi ser hos Nvidia med Fermi (som er demmes første nye arkitektur etter G80 som ble lansert i 2006)

 

Eneste årsaken til at ATi ikke støtter PhysX offisielt er fordi de ikke ønsket å implementere støtte for CUDA i sine drivere som PhysX baserer seg på.

Når det var aktuelt så var CUDA det eneste alternativet, skal ikke se bort i fra at det kommer en OpenCL-versjon av PhysX etterhvert som OpenCL blir litt mer modent.

 

Dette ønsket uavhengige 3. parter å gjøre noe med for godt og vel et år tid siden, så de la inn støtte for CUDA i ATi sine drivere og kjørte PhysX som en demostrasjon. Dette var ikke for å gi ATi kjøpere støtte for PhysX men for å vise at det helt greit lot seg gjøre og for å presse AMD til å endre beslutningen om å ikke støtte CUDA.

Stemmer at det ble lagd en primitiv "wrapper" mellom CUDA driver API kall og AMD CAL API kall.

 

GDI:

AMD har sagt til oss at Brook+/CAL (regner med at det er det du mener) er "dødt". De kommer til å satse på OpenCL og DirectCompute. Dette løser dessverre ikke problemene, da du allikevel må skrive bortimot dedikert kode for forskjellige arkitekturer.

Dette kan du bedre enn de fleste av oss på forumet, men jeg leste nå litt tilbake (6mnd?) at Streams 2.0, spesielt på HD5xxx, skulle gi et vesentlig ytelsesløft og ble vel demonstrert bla. i noen CS sammenhenger?

Aha! Da skjønner jeg hva du mente! :)

Det AMD snakket om her var at de la in OpenCL støtte i Stream SDK 2.0 (som er navnet på utviklingspakken). Stream SDK inneholder tre stk. API for å programmere AMD sine GPU'er. CAL (Compute Abstraction Layer) som er et "low-level" API. Brook+ som er en videreutvikling av

Stanford sitt Brook språk, dette ligner på C, og til slutt nå OpenCL.

DirectCompute (Compute Shaders) er en del av Microsoft sitt DirectX API, og ikke Stream SDK, og finnes i tre versjoner. Versjon 4.0 (DX10 hardware), versjon 4.1 (DX10.1 hardware) og versjon 5.0 (DX11 hardware)

 

HD5xxx serien gir sammenlignet med HD4xxx serien betydelig ytelsesboost i OpenCL og DirectCompute, hovedgrunnen til dette er at AMD har implementert en minnetype som ligger nærmere selve prosessorene i GPU'en. Denne minnetypen er kjent som local memory i OpenCL, i CUDA er den kjent som shared memory. Her deler 16 "stream prosessorer" 32kb med minne. AMD og Nvidia teller prosessorer på forskjellige måter, så her er det litt kaos... :p Shared memory vil gjøre at enkelte applikasjoner får en god ytelsesboost. Det er den største endringen som ble gjort med hensyn på GPGPU-ytelse i HD5xxx. Nå skal det også merkes at grunnen til at dette ble gjort er at det er et krav i DX11 med minimum 32kb med "shared" minne. Dette minne skal være både read og write. På HD4xxx er det kun read, ikke write, derfor må HD4xxx i OpenCL "emulere" dette local memory med DRAM på kortet noe som er myyyye tregere. Derfor er often OpenCL-ytelsen hvis ikke applikasjonen er tilpasset til å ikke bruke local memory elendig på HD4xxx. HD3xxx og HD2xxx vil på grunn av diverse mangler aldri kunne støtte OpenCL uten store hacks.

 

OpenCL og DC ( takk for påminnelsen ) er nok satsningsområdet videre ja, men som du sier fjerner ikke det alle arkitekturforskjeller, men har vi noe lag som egentlig gjør det? Eller kan man si at vi da nærmer oss en god felles grunn.

Vi har dessverre ingen lag som gjør dette. Utfordringene ligger i at selve regneenhetene (ALU) på Nvidia sin arkitektur ligger mye nærmere minne cacher enn på AMD sin arkitektur. AMD sin low-level arkitektur eksponeres som en SIMD (vektorisert) arkitektur, mens Nvidia sin eksponeres som en scalar arkitektur. vi har ut i fra våres forskning sett at det er mye enklere for en programmerer å tenke scalar en vektorisert. Man kan også se på AMD sin arkitektur som scalar, men da er det opp til kompilatoren å tilpasse koden til arkitekturen under, noe som krever en meget god kompilator, og det er nesten bare ett firma som er så gode på kompilatorer... Intel...

 

Det blir spennende å se hvor ting beveger seg i fremtiden. Vi får nok noen svar når AMD viser frem sin neste generasjons arkitektur, la oss håpe det blir "Northern Islands" (RV9x0)

 

Dette ble kanskje litt teknisk, bare spørre hvis det er noe dere lurer på! :)

Lenke til kommentar
Gjest Slettet+6132

<snip>

Dette ble kanskje litt teknisk, bare spørre hvis det er noe dere lurer på! :)

 

Blir aldri for teknisk. :)

Endret av Slettet+6132
Lenke til kommentar

Mange som sammenligner GTX480 med HD5970, 2x HD5870, 2x HD5850 (klassiker!) som da liksom skal gi mer ytelse for pengene osv..

 

Jeg må bare understreke at jeg syntes det å sammenligne single-GPU løsninger med multi-GPU løsninger er ren idioti, det er fremdeles alt for mye usikkerhet rundt hvor godt en multi-GPU løsning vil skalere i forskjellige spill, med forskjellige drivere osv til at det er sammenlignbart, med single-GPU vet du til en viss grad hva du får, med multi-GPU er det rene bingo.

 

Har vært borti HD4870X2, 2x HD5870, 2x GTX285 og GTX295 de siste årene og ingen av disse har blitt noe jeg har beholdt over tid, det er rett og slett alt for mye tull med både drivere, microstuttering, framedrops, artifacts som skyldes dårlig syncing mellom skjermkortene osv.. Det er rett og slett alt for mye som potensielt kan gå galt til at jeg ser på slike løsninger som noe kan sammenlignes head-to-head med ledene single-GPU løsninger..

 

 

Klart gir ikke HD5870 eller GTX480 nok ytelse alene så må du nesten bare spe på med flere i Crossfire / SLI, men på grunn av all problematikken som kan oppstå med slike løsninger og den fremdeles nokså variable skaleringen vi har så kan jeg ikke på noen som helst måte gå god for å anbefale slike løsninger.

 

 

En kollega av meg på jobb ble tvunget til å deaktivere sitt ene HD5850 kort når han skulle spille Bad Company 2, ellers så krasjet spillet nesten konstant? Ser vell ut til å gå fint med de offisielle 10.3 driverne, men fremdeles så er slike feil ting som rett og slett ikke burde oppstå om vi skal kunne se på Crossfire / SLI som fullverdige konkurrent mot single-GPU løsninger.

 

 

Det funker fint for å gi litt mer ytelse til et allerede eksisterende system da du kan spe på med et ekstra kort til det du alt har, samtidig gir det mulighet for potensielt høyere ytelse enn hva du klarer å få med det kraftigste single-GPU kortet, så gir ikke det i seg selv nok ytelse så kan det å kombinere flere være en utvei.

 

 

Men å sammenligne HD5970, 2x HD5850 osv med GTX480 som om de skulle være likeverdig blir for meg patetisk, mulig det er lett for meg å si dette ettersom jeg har hatt såpass mange frustrerende øyeblikk med både Crossfire og SLI opp igjennom, med både nyere og litt eldre kort, men uansett.

Lenke til kommentar

Man skal ikke klage på at GTX480 blir sammenlignet med multi-gpu. Sekundet etter at 5870 ble lansert kom det benchmark hvor den ble sammenlignet med GTX295 som jo er multi-gpu...

 

 

Det er jeg fullstendig enig i. I tillegg kan det jo nevnes at GTX480 og 5970 ligger i samme prisklasse, noe jeg mener gjør det naturlig å sette kortene opp mot hverandre. Når man kjøper skjermkort ønsker man jo ytelse for pengene.

Lenke til kommentar

Man skal ikke klage på at GTX480 blir sammenlignet med multi-gpu. Sekundet etter at 5870 ble lansert kom det benchmark hvor den ble sammenlignet med GTX295 som jo er multi-gpu...

 

 

Det er jeg fullstendig enig i. I tillegg kan det jo nevnes at GTX480 og 5970 ligger i samme prisklasse, noe jeg mener gjør det naturlig å sette kortene opp mot hverandre. Når man kjøper skjermkort ønsker man jo ytelse for pengene.

 

Joda, vi alle ønsker vell mest ytelse for pengene.. Problemet ligger mer i det faktum at det blir alt for ofte fremstilt at 2x 5850 i Crossfire = nesten en dobling av ytelsen.

 

Nå skaleres det riktignok veldig godt i enkelte tilfeller, men sannheten er jo at hva skal jeg med 2x HD5850 om jeg må vente flere uker etter et nytt spill har kommet før jeg oppnår noen som helst god skalering, om skalering i det hele tatt? Hva gir mitt HD5970 meg, eller mine to 5850, eventuelt to 5870 (you get the idea..) når spill som Bad Company 2 som er et av få spill hvor jeg faktisk trenger litt ekstra ytelse ikke vil kjøre med Crossfire aktivert overhode med de driverne som var tilgjengelig når spillet ble lansert?

 

 

Den type problematikk oppstår ikke med single-GPU løsninger, klart det kan komme drivere som gir deg litt bedre ytelse etter hvert med mer optimaliserte profiler osv.. Men det er veldig sjeldent snakk om natt og dag, en løsning med to skjermkort faller jo helt igjennom når du plutselig sitter der med mer eller mindre identisk ytelse som du ville hatt med kun et av kortene? Og slike frustrerende situasjoner har dukket opp alt for ofte de gangene jeg har prøvd meg på både Crossfire og SLI, om det så er interne eller eksterne broer vi snakker om.

 

 

Vi har jo også et eget lite kapittel med potensielle feil som kan oppstå når skjermkortene skal rendre halve bildet hver for seg, det kan bli synkronisering problemer i form av tearing som går midt over skjermen, flere opplever jo faktisk lille lyn som plutselig dukker opp midt over skjermen osv.. Blant annet så fungerte verken Crossfire eller SLI noe spesielt godt med Lord of the Rings Online når jeg prøvde det, enten var det massiv tearing midt over skjermen, eller så var det horisontale linjer. Deaktiverte jeg et av kortene, så var ikke dette lenger noe problem?

 

Må heller ikke glemme potensiell problematikk med microstuttering som kan gjøre at dine 40FPS på multi-GPU fort ikke nødvendigvis føles mer flytende enn hva 30FPS på single-GPU gjør, og du har vell jevnt over også flere og større framedrops med multi-GPU løsninger enn hva du har med single-GPU.

 

 

 

Alt dette tatt i betraktning så syntes jeg man skal være litt forsiktig med å varmt gå varm for den typen løsninger, jeg vil heller anbefale 1x HD5870 fremfor 2x HD5850 selv om sist nevnte kanskje kan (om det fungerer smertefritt) gi mer ytelse for pengene, HD5870 vil være et langt enklere, tryggere, sikrere og ikke minst mye mindre problematisk løsning som ikke er like driver og spill avhengig som 2x HD5850 eller 1x HD5970 for den sakens skyld vil være.

 

 

Derfor syntes jeg det blir litt rart å sammenligne GTX480 med HD5970 uansett, kan si de kanskje ligger i noe ala samme prisklasse, men hjelper fint lite når HD5970 på mange måter blir et langt mer "bingo" løsning enn hva noe single-GPU løsning vil være.

 

 

 

Den dagen vi kan med sikkerhet garantere minst 80% skalering i så godt som samtlige spill, nærmest uavhengig av driver, spill eller andre forhold og ting som driver problemer, microstuttering og annen problematikk er så godt som ikke eksisterende, først da kan vi se på multi-GPU og single-GPU som helt likeverdige løsninger etter min mening.

Lenke til kommentar

Ramguy: Har kjørt 4870X2 og et singel 4870 i trifire et år nå. Mulig jeg har vært heldig, da jeg til dags dato ikke har opplevd noe som helst problem med denne løsningen.

 

Ser du nevner problem med cf i Bad Company 2 med 5xxx kort. Gjelder dette spesielt 5xxx serien?

Endret av lucky666
Lenke til kommentar

Ramguy: Har kjørt 4870X2 og et singel 4870 i trifire et år nå. Mulig jeg har vært heldig, da jeg til dags dato ikke har opplevd noe som helst problem med denne løsningen.

 

Ser du nevner problem med cf i Bad Company 2 med 5xxx kort. Gjelder dette spesielt 5xxx serien?

 

De siste 10.3-10.3a-10.3b-10.3OGL4 sammen med siste Approfile, har hatt en CF profil som ikke har vært bra mtp Bad Company 2, og er et problem på enkelte oppsett, dette er nå prioritert hos ATI, og de forsøker fixe det. Tidligere drivere enn dette har jeg ikke testet med BC2, da det jo såvidt har kommet ut. Men, er man litt "savy" innenfor crossfire, så er det ganske enkelt å komme rundt disse problemene, rename .exe filen til BF2.exe, og det meste funker bra, det samme gjelder de fleste nye spill og eventuell manglende skalering etc....

 

Litt OT, men svarer litt mtp ramguy og lucky666 sine innlegg..

Lenke til kommentar

RamGuy: Jeg ser poenget ditt , men det er mye som gjør at det er en hel del "sense" i å sammenligne Nvidia GTX480 mot et AMD Radeon HD5970 eller 2x5850 for den saks skyld i akkurat denne runden. Det er blandt annet det faktum at GTX 480 sin watt klasse er godt stykke over det som AMD Radeon HD5970 befinner seg i ( men allikevel det mest sammenlignbare da du har en PCB og forholde deg til, og er nærmest), og det er etter min mening ganske så betydningsfullt. Og tesseleringsytelsen blir også litt mer sammenlignbar da, og så har du jo selfølgelig prisklassen til å bakke dette nesten så si fullt opp?

Lenke til kommentar
DirectCompute (Compute Shaders) er en del av Microsoft sitt DirectX API, og ikke Stream SDK, og finnes i tre versjoner. Versjon 4.0 (DX10 hardware), versjon 4.1 (DX10.1 hardware) og versjon 5.0 (DX11 hardware)
Det var jeg klar over, men glemte DC i denne sammenhengen og var en viktig påminnelse :).

 

Og et knallbra innlegg :thumbup:.

 

Du sørge for at utenforstående som ikke skal til vikingskipet får se foredraget ditt via webcast.

 

<snip>

Dette ble kanskje litt teknisk, bare spørre hvis det er noe dere lurer på! :)

Blir aldri for teknisk. :)

Jeg tipper at TL1000S, akkurat som meg, omtrentlig plasker som en yr vårfugl i dammene fra snøsmeltingen når vi leser slike innlegg. *ler*

 

GDI sitt innlegg ble en god og forfriskende avslapning i pausen fra annet teknisk slitsomt arbeid på jobb i dag.

Endret av Theo343
Lenke til kommentar
DirectCompute (Compute Shaders) er en del av Microsoft sitt DirectX API, og ikke Stream SDK, og finnes i tre versjoner. Versjon 4.0 (DX10 hardware), versjon 4.1 (DX10.1 hardware) og versjon 5.0 (DX11 hardware)
Det var jeg klar over, men glemte DC i denne sammenhengen og var en viktig påminnelse :).

 

Og et knallbra innlegg :thumbup:.

 

Du sørge for at utenforstående som ikke skal til vikingskipet får se foredraget ditt via webcast.

Om ikke webcast, håper jeg ihvertfall at noen har et videokamera med seg og føler for å dele, for dette høres unektelig spennende ut.

Lenke til kommentar
DirectCompute (Compute Shaders) er en del av Microsoft sitt DirectX API, og ikke Stream SDK, og finnes i tre versjoner. Versjon 4.0 (DX10 hardware), versjon 4.1 (DX10.1 hardware) og versjon 5.0 (DX11 hardware)
Det var jeg klar over, men glemte DC i denne sammenhengen og var en viktig påminnelse :).

 

Og et knallbra innlegg :thumbup:.

 

Du sørge for at utenforstående som ikke skal til vikingskipet får se foredraget ditt via webcast.

Om ikke webcast, håper jeg ihvertfall at noen har et videokamera med seg og føler for å dele, for dette høres unektelig spennende ut.

Kan sikkert høre med HW.no om vi eventuelt kan skrive en artikkel.

Vil også være tilgjengelig på UiO sin stand på TG for eventuelle spørsmål både på torsdag og fredag. Dessverre er et foredrag på 30 minutter liten tid til å fortelle om alt man ønsker... :)

Lenke til kommentar
Raptor' date='30. mars 2010 - 13:48' timestamp='1269953330' post='15436602']
DirectCompute (Compute Shaders) er en del av Microsoft sitt DirectX API, og ikke Stream SDK, og finnes i tre versjoner. Versjon 4.0 (DX10 hardware), versjon 4.1 (DX10.1 hardware) og versjon 5.0 (DX11 hardware)
Det var jeg klar over, men glemte DC i denne sammenhengen og var en viktig påminnelse :).

 

Og et knallbra innlegg :thumbup:.

 

Du sørge for at utenforstående som ikke skal til vikingskipet får se foredraget ditt via webcast.

Om ikke webcast, håper jeg ihvertfall at noen har et videokamera med seg og føler for å dele, for dette høres unektelig spennende ut.

Kan sikkert høre med HW.no om vi eventuelt kan skrive en artikkel.

Vil også være tilgjengelig på UiO sin stand på TG for eventuelle spørsmål både på torsdag og fredag. Dessverre er et foredrag på 30 minutter liten tid til å fortelle om alt man ønsker... :)

Må si meg enig med de andre her. Kommer meg ikke på TG, men det foredraget hadde vore offselig koselig å fått med seg :)

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...