Nvidia forbereder sommerlansering

[efikkan]

Beklager jeg graver opp en litt gammel diskusjon.

 

Grunnen til at mange spill er dårlig optimalisert for PC er at det er bare noen få som har veldig kraftige skjermkort, mens de fleste har i øvre mellomklasse. I tillegg finnes det ørten konfigurasjoner som gjør det vanskelig å optimalisere for alle. Det er derimot veldig mye enklere å optimalisere mot alle som har Xbox360 eller PlayStation 3, siden alle har samme maskinvare. Så konsollene får i snitt utnyttet kraften sin bedre, men så er moderne skjermkort til PC mange ganger kraftigere som veier opp og vel så det.

 

siindre: Ta deg en tur over i denne diskusjonen, som jeg er medskyldig i å avspore til diskusjon om skjermkort og optimalisering i spill. Se fra innlegg #63 og nedover.

 

For de som spiller en del så er det faktisk mest fornuftig å kjøpe nytt skjermkort hvert 1.5 - 2 år, og så kjøpe ny PC omtrent annenhver gang. Prismessig er det da lurt å legge seg rundt 2000 kr (eller litt mer) på det kortet som gir mest for pengene. Dette er mer fornuftig enn å kjøpe det sprekeste hvert 3 år (eller noe sånt), siden dette kortet vil etter 1.5 år bli utkonkurrert av skjermkort til rundt 2000 kr. Dermed er det altså lurere å kjøpe skjermkort til rundt 2000 kr oftere siden det gir bedre ytelse i snitt. Hvis gjeldende trender skulle endre seg, så må jeg komme med ny anbefaling. Men de siste fire årene har dette stemt ganske bra.

 

Selv så håper jeg på at GTX 460 får ytelse rundt HD 5850, koster rundt 2000 kr og at det kommer en løsning med en stille og effektiv kjøling. Det blir en sterk kandidat til en av maskinene jeg jobber med.

[MistaPi]

Klaging over dårlig optimalisering, rettvis eller ikke, kommer man nok til å høre mer og mer av fremover. Delvis pga diminishing returns med hva folk flest legger merke til (før vi hopper over på typisk film CGI kvalitet) og tildels pga forbedringer til den visuelle kvaliteten og dens krav til hardware ytelse blir litt som bil og luftmotstand, der det koster betydlig mer motorkraft per km/t når man kommer opp i høyere hastigheter.

Endret 15. mai 2010 av MistaPi

[efikkan]

Regnekraften til dagens GPUer er intet mindre enn enorm, og det er ingen tvil om at det er veldig mye å hente på optimalisering. Det er ikke så vanskelig å lage "god grafikk", det som er vanskelig er god grafikk med god ytelse. Et felt hvor jeg mener det ligger stort potensiale er å redusere kommunikasjonen mellom CPU og GPU til det absolutt minimale, det alene skal gi en merkbar forskjell, nVidia eksperimenterer en del med dette. Et annet felt er lure algoritmer for LoD (Level of Detail), her er potensialet enormt. Ved hjelp av kontinuerlig tessellation vil det i mange tilfeller være mulig å fjerne 2/3 av detaljene uten at bildekvaliteten blir forringet (dette er min erfaring og påstand), dette fordi at mange detaljer er rett og slett unødvendige. Jeg driver for tiden og leker meg ulike algoritmer, men noe som har irritert meg er mengden ram på skjermkort. Utviklingen kapasitetmessig har nesten stagnert de fire siste årene. Men dette kan selvsagt løses med å cache minst mulig i ram, og bruke en lynrask SSD, så jeg gleder meg virkelig til neste generasjon X25.

[Theo343]

Jeg er også en av de som mener vi burde ha gått til 2GB på toppkortene som HD5870 ol. forlengst. Men minnemengde er også relativ til bussbredde.

[efikkan]

Bussbredden har betydning, men ikke serlig mye i generell bruk. De faktorene som virkelig betyr noe er kapasitet og båndbredde (funksjon av bussbredde og frekvens). Kapasitet har stått relativt stille siden G80 kom, det har også bussbredden, men det som har reddet den effektive båndbredden er blant annet GDDR5. Hadde det vært opp til meg hadde toppkortene i dag fått 4 GB minne eller mer, det største problemet der er vel prisen. Det spørs om det blir et Quadro-kort i den ene maskinen min etter hvert, de får muligens opp til 6 GB minne.

 

Jeg vil påstå at båndbredden til minnet i skjermkort er i dag ikke noen serlig flaskehals, GTX 480 har 177.4 GB/s og HD 5870 har 153.6 GB/s. F.eks. IDs kommende spill Rage skal bruke megatextures og ha terreng med over 80 GB ukomprimert data, og det sier seg selv at dette løses ved hjelp av en slags "swapping" mellom disk/SSD og minnet til GPU. Poenget mitt er at til mindre størrelsen til minnet er, til mer hyppig må data overføres fra disk/SSD, behandles av CPU, så gjennom PCIe-bussen til GPU og så over i minnet der, mer kapasitet vil gi mindre belastning over hele systemet og vil dermed kunne gi bedre ytelse. Denne typen teknikk er så vidt brukt i noen få spill i dag, men vil trolig bli brukt mer og mer i spill fremover. Det blir spennende hvordan dette blir løst, men det vil ivertfall ikke gå mange årene før disker er for trege til enkelte spill.

[MistaPi]

Å komme opp med en regel på forholdet mellom minnemengde og båndbredde som samtidig tar for seg Xbox360 sin 10MB eDRAM med 256GB/s båndbredde og de individuelle GPU'enes egenskaper til å utnytte den tilgjengelige båndbredden blir vanskelig.

Store teksturer tar vel gjerne ikke så mye båndredde da det er det nærmest "kameraet" som trenger de veldig detaljerte teksturene.

[Theo343]

Det jeg mente er at du ser minnemengden variere kraftig ift. at bussbredden varierer på Nvidia kort. Med såkalte ukurante størrelser som 768MB osv. Og derav er ofte minnemengden relativ til bussbredden.

 

Bussbredden har ikke stått stille siden G80, den har variert på mange nvidia produkter siden det. ATI har også hatt forskjellige bussbredder og gikk ned til 256bit igjen pga. høyt klokket GDDR5.

 

Båndbredde har aldri vært noe problem da selv GDDR3 ga Nvidia nok båndbredde i kombinasjon med høy klokkefrekvens og bredere buss.

Endret 15. mai 2010 av Theo343

[efikkan]

Det er ingenting i veien for å sette på 3GB eller 6GB på et GTX 480, men det må selvsagt være et multiplum som går opp i bussbredden.

[MistaPi]

Båndbredde har aldri vært noe problem da selv GDDR3 ga Nvidia nok båndbredde i kombinasjon med høy klokkefrekvens og bredere buss.

Ja det er imponerende å se hvor balansert 5870 er mtp at Cypress er det dobbelte av RV790, men har bare 23% mer minnebåndbredde enn 4890.

Går man lenger tilbake sultet skjermkortet en del på båndbredde, ihvertfall når det kom til FP HDR og MSAA. MSAA var veldig kostbart før Radeon 9700Pro kom med 256bit minnebuss og farge komprimering.

[Theo343]

Det var litt for drøyt av meg å si "har aldri vært noe problem" men så generøs som du er skjønte du hva jeg mente Selv husker jeg med glede 9800Pro Atlantis kortene som stakk seg ut her.

Endret 15. mai 2010 av Theo343

[efikkan]

Én ting som ikke alle er klar over er at all SM4-maskinvare fra ATI og nVidia støtter hardware-tessellation, men ikke like fleksibelt som SM5. Men det jeg har sett/kjørt av eksempler til nå er ivertfall mulig å få til på SM4, og GPUer som GTX 285 og 295 skulle fint kunne dratt nytte av det.

[MistaPi]

Én ting som ikke alle er klar over er at all SM4-maskinvare fra ATI og nVidia støtter hardware-tessellation, men ikke like fleksibelt som SM5. Men det jeg har sett/kjørt av eksempler til nå er ivertfall mulig å få til på SM4, og GPUer som GTX 285 og 295 skulle fint kunne dratt nytte av det.

Så du sier at tessellation er mulig å gjøre via shadere, blir ikke dette da en software løsning? DX10 kortene til ATi har dog en tessellator enhet.

[efikkan]

Én ting som ikke alle er klar over er at all SM4-maskinvare fra ATI og nVidia støtter hardware-tessellation, men ikke like fleksibelt som SM5. Men det jeg har sett/kjørt av eksempler til nå er ivertfall mulig å få til på SM4, og GPUer som GTX 285 og 295 skulle fint kunne dratt nytte av det.

Så du sier at tessellation er mulig å gjøre via shadere, blir ikke dette da en software løsning? DX10 kortene til ATi har dog en tessellator enhet.

Hvis det er en softwareløsning så er det CPUen som gjør jobben, og det er ikke det jeg snakker om (det er forsåvidt også mulig, men lite hesiktsmessig). SM4-maskinvare (usikker hva Intel har) har en fixed tessellator, SM5 har i tillegg en programmerbar. På SM4 må vel og merke vertex-shaderen tilpasses litt. Les denne artikkelen

nVidia har også tilsvarende funksjonalitet, med noen detaljer.

[MistaPi]

Hvis det er en softwareløsning så er det CPUen som gjør jobben, og det er ikke det jeg snakker om (det er forsåvidt også mulig, men lite hesiktsmessig). SM4-maskinvare (usikker hva Intel har) har en fixed tessellator, SM5 har i tillegg en programmerbar. På SM4 må vel og merke vertex-shaderen tilpasses litt. Les denne artikkelen

nVidia har også tilsvarende funksjonalitet, med noen detaljer.

Ok, takk for oppklaringen. Jeg hadde fått inntrykk av at det var bare ATi sine DX10 kort som hadde en tessellator, så det var nytt for meg at nVidia også har en tilsvarende løsning på sine DX10 GPU'er.

 

One item of note near the vertex assembler is a dedicated hardware engine for tessellation. This unit is a bit of secret sauce for AMD, since the G80 doesn't have anything quite like it.

- http://techreport.com/articles.x/12458/2

 

 

Er forøvrig softwareløsninger så ensbetydende med CPU lengre? Tenker her bl.a på GPGPU bruk med CUDA etc. Det er vel ikke så veldig mange dedikert/fixed-function enheter igjen iforhold til arealet av en moderne GPU'en som går med til programbare ALU'er.

Endret 16. mai 2010 av MistaPi

[efikkan]

Hvis det er en softwareløsning så er det CPUen som gjør jobben, og det er ikke det jeg snakker om (det er forsåvidt også mulig, men lite hesiktsmessig). SM4-maskinvare (usikker hva Intel har) har en fixed tessellator, SM5 har i tillegg en programmerbar. På SM4 må vel og merke vertex-shaderen tilpasses litt. Les denne artikkelen

nVidia har også tilsvarende funksjonalitet, med noen detaljer.

Ok, takk for oppklaringen. Jeg hadde fått inntrykk av at det var bare ATi sine DX10 kort som hadde en tessellator, så det var nytt for meg at nVidia også har en tilsvarende løsning på sine DX10 GPU'er.

Som du sikkert er klar over skulle tessellation bli den største nyheten i DirectX 10 i sin tid (forøvrig i DirectX 9 før det, men det kom ikke så langt som til maskinvaren i en fornuftig form, men ATI styrte på med noe eksperimentelt). Men både nVidia og AMD/ATI har implementert fixed function tessellation i maskinvaren. AMD/ATI har det som tillegg til DirectX 10, og har demoer på det, noe jeg ikke kommer på om nVidia har, så det er kanskje det du tenker på. Begge har det i OpenGL som utvidelse ivertfall i omtrent 3.5 år. Jeg har lekt mest med AMD/ATI sin variant, og den virker veldig kraftig og fint, bortsett fra at AMD klarer å gjøre en del bugs i driverne sine, som folkene i Unigine syter kraftig om. Det fungerer til og med i Ubuntu, og all funksjonalitet som f.eks. Unigine Heaven viser i DirectX 11 (og snart i OpenGL 4.0 når neste patch kommer) går ivertfall på AMD/ATIs SM4-maskinvare. Det er snakk om små plagsommme bugs som varierer fra hver versjon av catalyst, kan nesten virke som AMD gjør ting med vilje, men jeg skal ikke påstå at de gjør slikt for å selge SM5-maskinvare.

 

Jeg kjørte senest i går en demo med nVidias tessellation på min slepbare "laptop" med GeForce 8700m GT, det fungerte men jeg har ikke testet det grundig. Det jeg har observert er at nVidias går til en faktor på 32, mens AMD/ATI går "bare" til 15 (det vil si antall punkt som er tessellert mellom to punkt). I DirectX 11 går det til 64. I OpenGL 4.0 har jeg ikke sjekket, jeg har ingen SM5-maskinvare tilgjengelig. Men tessellation-faktoren er uansett ikke "mangelen" med SM4 på nåværende tidspunkt. Men jeg har ivertfall testet at AMD/ATIs støtte i SM4 støtter kontinuerlig tessellation (har ikke prøvd å få dette til på nVidia ennå, skal se om jeg får tid en gang) som ivertfall er veldig viktig for det som jeg ønsker å bruke tessellation til. De fleste demoer rundt omkring bruker "discrete tessellation", altså kunn heltallsfaktorer, som gjør at objekter og terreng plutselig får flere detaljer ved bevegelse, og for å skjule dette må eventuelt detaljene dukke opp så tidlig at vi ikke oppdager forskjellen, og da er litt av poenget med LoD borte. Det som er mulig med kontinuerlig tessellation er altså at nye vertices dukker opp i de eksisterende og gradvis "glir på plass" slik at spilleren ikke ser at detaljer dukker opp, bare får et jevnt og flott bilde med ferrest mulig unødvendige detaljer. Det bør nevnes at AMD/ATIs og nVidias implementasjoner i OpenGL har en del forskjeller, dette skyldes måten de har valgt å gjøre det i drivere.

 

<spekulasjon>Det kan virke som at nVidia ikke var fornøyd med sin tessellator i SM4-maskinvare, selv om den kan klare mye bra. Eller det kan rett og slett være at de ikke ble enige i tide om hvordan det skulle implementeres i DirectX.</spekulasjon>

 

 

Er forøvrig softwareløsninger så ensbetydende med CPU lengre? Tenker her bl.a på GPGPU bruk med CUDA etc. Det er vel ikke så veldig mange dedikert/fixed-function enheter igjen iforhold til arealet av en moderne GPU'en som går med til programbare ALU'er.

Nei, det er ikke i den betydning. Jeg er enig i at definisjonen er litt diffus, men jeg bruker den betydningen som er vanlig, altså at en prosessor ved hjelp av programvare implementerer maskinvarefunksjonalitet til en annen prosessor, da blir det emulert i programvare. Fixed-funksjonalitet i en GPU er fremdeles maskinvare, men åpenbart veldig begrenset samt at det er avhengig av styringskall fra CPU som medfører venting og synkronisering. Shadere, enten på høynivå (GLSL, HLSL, Cg) eller på maskinkodenivå i Direct3D eller OpenGL utnytter funksjonene til GPUen direkte. Det er mulig jeg formulerte noe litt dårlig her tidligere, jeg skriver i de små nattetimer. Det jeg mente var ivertfall at det er mulig å implementere tessellation ved hjelp av CPU, altså at CPUen genererer det som tessellator i GPU egentlig skulle gjort, men dette vil ikke være hensiktsmessig med tanke på ytelse.

 

Her kan du se instruksjonssettet i SM5 for nVidia i maskinkode, bla ned til "Modify Section 2.X.4, Program Execution Environment".

 

Du får skrike ut om jeg forklarte ting dårlig eller gjorde ting verre nå, har ikke hatt en ordentlig natts søvn på måneder nå...

Endret 16. mai 2010 av efikkan

[MistaPi]

Jeg syns det er helt greit forklart, og takk for at du tar deg tiden til det. Så får du ha lykke til med nattesøvnen fremover. Jeg er selv ikke ukjent til søvnløshet, 4 år med skiftarbeid til alle døgnets tider har satt sine spor.