Fredagsfokus 3: Directstorage, Velocity Architecture och RTX IO

Det här är ju något som är sjukt relevant nu inför lanseringen av nya konsollerna och nya grafikkort!

Nästan så att dessa kortare fredags-filmer passar bättre, kan dom komma oftare? Eller kanske lite on-demand?

Ja men AGP var fortfarande bara en kommunikationsväg mellan processorn, moderkortet och grafikkortet, den kopplade inte samman grafikkort och lagring.

Den största skillnaden mellan PCI och AGP var att den sistnämnda var dedikerad kommunikation med grafikkortet, medan PCI var en delad buss som blev begränsad i takt med att grafikkorten började bli allt mer bandbreddskrävande.

AGP var väl ’bara’ PCI x8 om jag minns rätt.

Var det inte så att RTX IO skulle väl fungera på Turing RTX också (dock såklart med PCIe3 såklart)? Så ännu mindre anledning att köpa av den anledningen...

@medbor: Enligt https://www.techspot.com/news/86601-nvidia-rtx-io-technology-... ska det gälla både Turing och Ampere. Så ganska snart vore det väl ändå en hyfsat stor andel som har grafikkorten i alla fall. Men NVME användning kanske dröjer...

Attans! Vill ju ha det som PS5an erbjuder!

EDIT: Med det sagt, utradering av laddningstider är inte så dumt det heller. https://www.youtube.com/watch?v=XmLYh1ybLqs

EDIT2: Och efter att ha kollat lite mer på Ratchet and Clank... hur ofta är det egentligen den typen av laddning kommer behövas i spel? Coolt att teleporteras från en plats till en annan, men vanligaste scenariot när detta sker är ju vid fast-travel och i det läget borde det väl gå att köra både IO och traditionellt samtidigt? Visst, supercoola sekvenser från värld till värld blir svårt men när används det annars? Snabbtransport över lång distans kanske med snabb streaming?

Ratchet & Clank är ju snudd på bara ett teknikdemo för vad som är möjligt. Det handlar mer om att dagens spel artificiellt måste begränsas på olika sätt därför att I/O-prestandan varit så dålig på majoriteten av alla system att det inte varit tekniskt möjligt att få fram data i den takt som spelet annars skulle kunna rendera grafik till. Det är alla möjliga knep som används för att begränsa spelarens möjlighet att röra sig i spelvärlden eller att kunna se saker på långt håll, typ att du måste gå igenom dörrar/portaler/åka hiss för att komma till en annan del av kartan, att fordon har en märkbart begränsad toppfart (t.ex. bilarna i GTA V), att allt utanför en viss radie runt avatarens synfält mer eller mindre bara är en kuliss av lågupplösta texturer (Fallout & Skyrim).

Det har ju varit såhär sålänge dataspel har funnits, så det är väl inte så förvånande att många ser det som något normalt att spelvärlden är segmenterad i mindre delar.

Det gick faktiskt att "ha sönder" Forza Horizon 4. Bilarna i spelet är begränsade till ungefär 450-455km/h (Koenigsegg) men det finns en bil (Ferrari FXX Evo) som buggar ur lite och kan nå över 500km/h. Spelar man på Xbox one med hårddisk så kan inte spelvärlden laddas in tillräckligt snabbt och det försvinner texturer hejvilt. Det händer inte när jag spelar på PC med nvme.

Processorn kan absolut trycka massa data (texturer etc) till grafikkortet mycket snabbare än några MB/s om du har en SSD (även sata).

Den enskilt största vinsten med detta är minskad VRAM-användning eftersom GPU kan nu packa upp komplexa komprimerade format själv och hålla allt komprimerat längre (RT-kärnor är mer generella och kan göra denna typ av algoritmer mycket mer effektivt vs traditionella gpu kärnor), och den kanske största vinsten är att CPU inte längre behöver dedikera massa trådar till upp-packning och överföring av data längre.

Bytet till NVME för gamers hade alltså ökat möjligheten till lägre laddningstider och streaming av resurser redan utan denna teknik.

Skillnaden är alltså att cpu räknar fram pekaren till vart informationen finns på disken, och det enda som överförs från cpu till gpu är dessa pekare, sen hämtar GPU informationen direkt från ssdn. Det är inte mer magiskt än så vad jag förstått

Jag syftade på system där primärlagringen består av en hårddisk. Av tekniska skäl är det ju som bekant uteslutande sekventiella överföringarna som kan ske med något hundratal MByte/sek, prestandan går genom golvet så fort sökning är inblandad, där en modern HDD har ca 80 IOPS för 4 KB-läsning mot en typisk SATA-SSD idag som har ca 10000 IOPS i samma scenario.

Jo, det finns många sätt att använda tekniken på. Jag tror det är svårt att förutspå vad den största vinsten kommer att bli, det hänger dels på spelens uppbyggnad och på hur utvecklarna väljer att implementera tekniken.

I normala fall är det ett väldigt skyfflande av data fram och tillbaka till RAM innan den ska skyfflas vidare till RAM. Det är många latenser på vägen, och smala bussar att försöka trycka data genom samtidigt som allt annat som händer i systemet ska gå genom dem. Man kapar bort en hel massa onödiga steg med Direct Storage.

Detta med I/O-prestanda som tar knäcken på CPUn förekommer även i andra scenarion, som LTT nämner i sin video nedan.

Detta är skitbra. Entusiaster har länge inte klarat sig på sata hastigheter på deras ssd, problemet med nvmve ssd har dock varit att de typ har varit dubbelt så dyra. Detta samtidigt som de har behov av att ha betydligt större lagringsutrymme och det blir svindyrt.

Men detta kommer leda till att en större skara har behov av både snabbare och större ssd, detta i sin tur driver på utvecklingen och resultatet blir väl snart att prisskillnaden mellan sata och vanliga nmve ss blir försumbar. Sedan skulle väl sata eller något behöva göras om, 550MB/second blir en flaskhals redan vid filöverföring i ett 10Gbit nätverk.

Hm, jag ser det här argumentet lite här och där på sweclockers och andra forum, men ingen har faktiskt länkat en källa där Nvidia bekräftar att så är fallet. Kan du vidareutveckla eller länka källa?

Att ligga med komprimerad data i vram gör ju ingen nytta, eller så är det jag som missförstår något.

Ofta läses saker in innan de behövs, nu kan dessa saker vara komprimerade tills de behöver användas. Det är inte så att hela grafikminnet rensas inför varje frame utan saker som tillhör världen/området och andra saker kan finnas i VRAM långt innan de används då de behöver vara redo om man vrider kameran åt rätt håll till exemepel. Denna typ av cachade saker kan då ta mindre plats jämfört med traditionella grafikort eftersom det inte var realistiskt att dekomprimera dessa i realtid på raster-resurserna eftersom det är riktigt ineffektivt.

Hur stor skillnad det gör i praktiken är svårt att säga och beror nog mycket på resurserna som lagras och hur stor del av VRAM som agerar cache. Men 10% är inte en orimlig siffra tror jag

Koncepten kanske blandas ihop något. Precis som du säger kommer man inte placera komprimerad data i vram. däremot kan assets ligga på din ssd komprimerat säg 2:1. När du läser in det kan du dekomprimera det i realtid och på så vis får du ”dubbelt så hög överföringshastighet”

Däremot slipper man ju hålla onödiga saker i ram om man har snabb access till att läsa in dem till ram på millisekunder istället för typ 5, 10 eller 30 sekunder.

Och när directstorage kombineras med sampler feedback streaming där bara de direkt nödvändiga Mip-nivåerna (just ”nu”) laddas in kan man reducera minnesanvändningen ytterligare.

Men man ska nog knappast se det som ”möjlighet att ha mindre vram på framtida grafikkort”
Snarare kommer ju spelutvecklare vilja använda det minne de frigör till ännu mer detaljerade assets etc.

Om man vänder lite på det hela:
Ps5 har vassare lagring, x har lite vassare gpu.

Dvs Sony har jämförelsevis med x prioriterat lagring över mer traditionellaprestabdaresurser” jämfört med x.

Du verkar tolka det som om det var en negativa kritik men så tolkade inte jag det. Men @loevet vet bäst själv

@Kriistoffer: nej precis som @UndaC skriver menade jag inte att Sony nedprioriterat grafik på något sätt, det är ju en hyggligt viktig komponent för en spelkonsol Jag menade mer att Sony satte ett högt bandbreddskrav för lagringen som en hög prioritet för PS5, medan MS fokuserade mer på att erbjuda bra hästkrafter både för grafik och lagring. Mark Cerny har ju vid flertalet tillfällen sagt att deras undersökningsprocess för PS5 (och även med PS4) bestod i att få en bild av vilken balans i hårdvarans konfiguration som var viktigast för utvecklare, och utöver den balansen har de satt ett eget mål om riktigt hög lagringsprestanda. Jag tycker också balanser ser ut att ge en riktigt välavvägd helhet, och 3D-ljud via Tempest-motorn är något jag verkligen ser fram emot att uppleva.

Gällande kapacitet för grafik ska man också ha i åtanke att fler beräkningsenheter (CU:s) i Xbox Series X inte bara innebär bättre shaderprestanda. Varje CU i RDNA 2 innehåller också ett antal enkla beräkningsenheter för ray tracing, och ett större antal CU:s ger då också XSX bättre kapacitet för RT-beräkningar. Där har Sony nog gjort den avvägningen att det antal PS5 är utrustad med är "good enough". I slutändan tror jag dock inte att PS5 kommer få en stor nackdel för RT, utvecklare lär utnyttja de tillgängliga resurserna smart för enklare ljussättning eller skuggning, och de som utvecklar multiplattform kan skruva upp RT-nivån ett snäpp på XSX.

Ja jo, det är ju hela grundprincipen förstås.

Jag argumenterade bara emot att "huvudsyftet" skulle vara att spara på VRAM eller använda VRAM som cache för komprimerade texturer så att säga.

Huvudsyftet skulle jag snarare definiera som att "drastiskt öka hastigheten i GPUns åtkomst till lagringsenheten och samtidigt eliminera behovet för omvägar som belastar andra subsystem".

Angående att cacha komprimerade texturer i VRAM så hade man ju strikt talat kunnat göra det utan att blanda in resterande delar av Directstorage ("nvme-delen" om man så vill). Jag tänker snarare än att använda VRAM som cache så är typ hela poängen här att man kan börja använda NVME-enheter som cache. Iaf så som det har beskrivits av de tre iblandade aktörerna.

Så jag uttryckte mig nog lite för kategoriskt att man "kommer man inte placera komprimerad data i vram". Snarare: det kanske man kan men det är inte det varken Sony, Nvidia eller Microsoft har pratat om. (Just nu vet vi inte ens om en sådan funktionalitet kommer att exponeras i DX/DS)
På PC låter det ju fullt möjligt, på konsolerna som har decompressionblocks som sitter utanför GPUn kanske det blir lurigare. På PS5 skulle det behöva färdas fram och tillbaka över PCIe ett varv (plus den initiala överföringen då också förstås) t.ex. Har inte sett någon detaljerad skiss på var i kedjan Microsofts decompressionblocks sitter dock.

Håller helt med. Huvudsyftet lär vara just att minska påverkan på CPU, framförallt på konsolerna vars primära uppgift är att köra spel. Att skyffla stora mängder data via CPU i realtidskritiska applikationer som spel är att be om problem, för spel i form av stutter.

Och visst är det tekniskt möjligt att hålla komprimerade texturer i VRAM och packa upp den med GPU redan idag. Problemet är att det inte är helt trivialt att få till och idag finns det inte som standardfunktion, så spel som skulle vilka göra något sådant skulle behöva skriva all hantering via compute-shaders och få det att fungera väl med alla GPU-modeller man vill stödja.

Direct Compute flyttar ju implementation av tekniken till Microsoft (OS-stöd) och GPU-tillverkarna (stöd i drivers). Gissar därför att vi som en trevlig bieffekt av denna teknik också kommer få bättre utnyttjade av VRAM då man rimligen kommer börja hålla delar av texturer komprimerade i VRAM.

Verkar som att du, jag och @UndaC är ganska överens ändå

Edit: (Citerade visst fel inlägg...)

Nu har jag blivit lite förvirrad.

Är inte texture redan komprimerat i VRAM och har varit så dom senaste +5-åren.
Ser annars inte att både Nvidia och AMD skulle prata om komprimering.
ASTC som ex. presenterades 2012

S3TC har funnits sen DX6,0 / Open GL 1,3

Kraken och liknande lossless-komprimeringar brukar ligga som ett lager utöver dessa när resurserna är sparade på disk. De tekniker du nämner är väl mer för att öka prestanda i runtime men får också en bra effekt med mindre vram användning.

Dock ska man inse ganska snabbt att all ät ledigt vram snabbt fylls med lite bättre högupplösta texturer och liknande, så det går ju inte till spillo

Nästa steg är kanske spel-"cache" i form av stor, billig RAM-modul med (för att vara RAM, låg hastighet, men många gånger snabbare än SSD) som kan direktstyras för att förhandslagra "grafikdata" som är i närheten och kan behövas med kort varsel beroende på var spelaren är för tillfället. Säg 8-16 GB. Ett beredskapslager. Som då naturligtvis ska vara direkttillgängligt för grafikkortet enligt den där principen som avhandlas i tråden.