Gå til innhold

Test: Asus GeForce GTX 680 DirectCU II 4 GB


Anbefalte innlegg

Jeg tenkte ikke på en gitt oppløsning eller innstilling, jeg tenkte på hvor mye VRAM som var praktisk mulig å bruke for et GTX 680 i spill, for dette er

 

Poenget er at om et skjermkort med 192GB/s med båndbredde skal levere 60 bilder i sekundet holder det med 2GB med VRAM, om kompresjon er i bruk eller ikke har ingenting å si på hvor mye VRAM som kan brukes (jeg antar at data fortsatt er komprimert når det ligger i VRAM.) Ellers kan det brukes til caching for å redusere lastetider, men med minst 4GB/s mot CPU burde ikke behovet for å lagre ekstra data i VRAM for caching være så voldsomt stort.

 

For å kunne nyttegjøre seg mer VRAM må man derfor øke tidsbudsjettet for skjermkortet, eneste måte å gjøre dette på er å senke framerate-målet (enten ved å akseptere lavere framerate eller bruke alternate frame rendering og flere GPUer.)

Framebufferet blir ikke komprimert. Z og farge komprimering er lossless teknikker som reduserer minnetrafikken, ikke datamengden i minne. Det er heller ikke bare snakk om komprimering, men også occlusion culling.

All type data bruker ikke like mye båndbredde. Større teksturer bruker gjerne langt mindre båndbredde iforhold til å øke datamengden i minne like mye med høyere oppløsning.

Det kan være en stor fordel å ha mye teksturer/modeler i minne slik at man unngår at spilleren plutselig løper inn i et område med teksturer som ikke ligger i vram.

Lenke til kommentar
Videoannonse
Annonse

1 til 1.5GB med data per frame?

Trafikken kan nærme seg det nivået dersom oppløsningen er stor nok (over flere skjermer) og/eller høy nok grad av AA brukes (GeForce støtter opptil 32x CSAA, Quadro 128x).

 

Det er heller ikke slik at all data som ligger i vram må brukes i hver eneste frame for at det skal å noe fordel i å ligge der.

Det er det heller ingen som har påstått. VRAM er fylt med div. tekstur- og vertexbufre (disse er typisk relativt statiske), pluss en eller flere (frame-)bufre som brukes svært aktivt. Det er ganske vanlig at refleksjoner tegnes til en midlertidig buffer før det tegnes til framebuffer. Som nevnt vil 2560x1600 med 16x MSAA oppta 250 GB (+overhead), og vil minimum medføre 500GB/frame i trafikk for et enkelt renderpass.

 

Hadde det vært opptil meg å designe GPUer så ville jeg laget to nivåer av VRAM, f.eks. med 1.5-2 GB på en bred rask buss, og 8-16 GB "tregt" og billigere minne på en egen buss til teksturdata og lignende. Det hadde også vært nyttig å kunne overføre til dette minnet uten å forstyrre GPUen.

 

Poenget er at om et skjermkort med 192GB/s med båndbredde skal levere 60 bilder i sekundet holder det med 2GB med VRAM, om kompresjon er i bruk eller ikke har ingenting å si på hvor mye VRAM som kan brukes (jeg antar at data fortsatt er komprimert når det ligger i VRAM.) Ellers kan det brukes til caching for å redusere lastetider, men med minst 4GB/s mot CPU burde ikke behovet for å lagre ekstra data i VRAM for caching være så voldsomt stort.

 

For å kunne nyttegjøre seg mer VRAM må man derfor øke tidsbudsjettet for skjermkortet, eneste måte å gjøre dette på er å senke framerate-målet (enten ved å akseptere lavere framerate eller bruke alternate frame rendering og flere GPUer.)

BPTC/BC7 og lignende er fremdeles komprimert i VRAM ja, det er hele poenget. Slike former for komprimering fungerer ved at den komprimerte teksturen matches opp mot faste mønstre, noe GPUen gjør på direken.

 

Men selv på denne minnebussen kan mer minne utnyttes til å lagre teksturdata. Spill i dag bruker typisk mye coherent noise og former for "detail maps", disse lagres enten som teksturer eller det brukes mye regnekraft på å generere dette på direkten. Hvis dette ble byttet ut med teksturer i høyere detaljer så kunne GTX 680 fint utnyttet 8 GB VRAM. La meg ta et eksempel for å illustrere:

La os si et førstepersonsspill tegner et terreng-utsnitt med en 512²-tekstur, som GPUen blander med et repeterende 8192² detail map. Hvis dette byttes ut med et utsnitt i 8192² i stedet for, så vil minnetrafikken mellom GPU og VRAM per frame faktisk reduseres, men det introduserer et nytt problem, nemlig at VRAM nå får mindre plass til terreng-utsnitt, og å transportere data over PCIe-bussen ksoter mange GPU-sykler. Dette er grunnen til at spill ikke utnytter mer VRAM, minnebussen mellom GPU og VRAM er mer enn tilstrekkelig så lenge oppløsning + AA ikke blir for stort.

 

All type data bruker ikke like mye båndbredde. Større teksturer bruker gjerne langt mindre båndbredde iforhold til å øke datamengden i minne like mye med høyere oppløsning.

Det kan være en stor fordel å ha mye teksturer/modeler i minne slik at man unngår at spilleren plutselig løper inn i et område med teksturer som ikke ligger i vram.

Kan du forklare dette bedre? :)
Lenke til kommentar

Med denne artikkelen kan vi konkludere at det er ingen vits i det hele tatt å kjøpe 4GB 680. Skal du spille på 2560x1600/1440 så holder AMD sitt 7970 i massevis. Den har litt mindre minne, men til gjengjeld har den en bredere minnebuss. Hadde vært kult å se test oppsett med flere 2560x1440/1600 skjermer.

Lenke til kommentar

Kan du forklare dette bedre? :)

Jeg tenkte vel mer på texture streaming, noe som kan begrense utviklerene mtp at man må passe på at spilleren ikke se mer enn det man kan ha i vram (begrense hva som er synlig og level design forøvrig). Samt passe på data laster raskt nok til at spilleren ikke beveger seg inn i områder som ikke har teksturer/modeler klart i vram.

 

Når det gjelder det førstnevnte så sikter jeg til det du selv skriver om teksturdata, at "minnebussen mellom GPU og VRAM er mer enn tilstrekkelig så lenge oppløsning + AA ikke blir for stort."

Nå ser det ut som at neste generasjons konsollene vil få ganske greit med minne ifølge ryktene (4-8GB), så det lover jo godt med å få øket vram og utnyttelsen av det også på PC.

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...