AMD siktar på dubblerad FPS med FSR 3

Mjo, interpolerade bilder behöver per definition skapa latens, men inte extrapolerade.

Interpolation betyder att man skapar något mellan två saker, t.ex. en extra frame mellan frame "1" & "2", låt oss kalla den "1.5". "1.5" kan inte skapas förens vi har både "1" och "2", så för att få en mjuk resultat behöver du fördröja "2" med en halv frame-tid + tiden det tar att beräkna fram "1.5".

Det ser du också i presentationen från AMD som finns inbäddad i artikeln. Den första "present" där kommer från att man beräknar fram just "1.5" från den nya framen och föregående. Den faktiskt framen som beräknats fram där visas sedan lite senare, när man håller på att rendera nästa frame etc.

Extrapolering vet jag inte om någon gör, men jag tyckte jag såg någon sådant på en slide från nVidia. Då tar man och utgår från senaste framen och extra info för att försöka lista ut vad nästa frame ska vara, och kan då visa den i förtid. Men det är en gissning, om det är rätt vet man inte fören en stund senare när "facit" kommer i form av nästa färdiga frame.

Men för personer som är intresserade av den här typen av teknik så spelar det väl mindre roll om bilden fördröjs en halv (+ lite till) frame. Vid 30fps som blir 60fps talar vi om kanske 4ms extra latens, inget jag bryr mig om det minsta.

Förstår inte gnället med dessa tekniker. DLSS 1.x och FSR 1.x hade ett gäng problem, men redan då var det ju valfritt att använda tekniken och är fortfarande valfritt.

Tycker DLSS 2.x och FSR 2.x fungerar superbra i en klar majoriteten av fallen. Skulle inte så vara fallet går det att slå av.

Pratas väldigt mycket om ghosting. Visst kan detta synas i stillbilder, men i rörelse är det långt färre fall där det i praktiken är ett problem.

Tycker det egentligen bara finns ett återkommande problem hos FSR 2.x, det orsakat av något som AMD kallar Thin Feature Locking. FSR 2.x har en tendens att göra tunna linjer tjockare/mer synliga än de borde vara. Syns främst på elkablar i luften, men kan även uppträda på raka saker med stor kontrast som träpaneler.

Dock verkar just ghosting kunna vara något som kommer vara extra utmanande med FSR 3.x om jag förstått AMD rätt (var på deras presentation kring detta på GDC). De tekniker man använder för att eliminera/minska denna artefakt hos FSR 2.x är inte möjliga i FSR 3.x. Vi lär få se hur bra/dåligt detta fungerar.

Angående DLSS 3.x så är sättet Nvidia implementerat det hela gjort på ett sätt som faktiskt utesluter GPUer som saknar HW-stöd för "Optical Flow Acceleration". Väldigt förenklat kan man se det som att DLSS/FSR 2.x jobbar på "vertex-shader" nivå, man tittar på geometrin hos objekt och hur de förflyttar sig mellan två bildrutor.

DLSS 3.x jobbar i stället på "fragment-shader" nivå, d.v.s. "Optical Flow" är att man räknar/uppskattar ut hur varje individuell pixel rör sig mellan två bildrutor för att på så sätt kunna bilda sig en uppfattning var respektive pixel då var halvvägs mellan dessa två bildrutor.

Här lär FSR 3.x behöva använda sig av någon annan teknik, så blir spännande att se hur bra/dåligt det fungerar.

Helt rätt, jag borde inte räkna i huvudet idag märker jag.

Men cirka 20ms extra spelar mig inte så mycket roll det heller, om det ger mig trevligt flyt.

Dock förstår jag att de som vill ha snabba reaktioner hellre har riktig 60fps med 15ms fördröjning än 30->60fps med totalt kanske 50ms. Men det senare är betydligt billigare i plånboken.

Sedan finns det andra användningsområden också. Att tex aktivt slå på det bara i cut-scener då latens blir totalt oviktigt.

Det var en rätt ordentligt förenkling kring flera saker jag skrev, inklusive DLSS 3.x.

DLSS 3.x går att "köra" lika bra som det går att "köra" saker med hårda realtidskrav på Windows/Linux. I praktiken: inte alls.

Logiskt sett går det att köra på vilken GPU som helst. Men en kritisk dimension för DLSS 3.x är att alla DLSS 3.x-relaterade operationer alltid kan slutföras på < 1/(2*FPS) sekunder, missar man den dead-line:en fungerar det inte.

Redan Turing fick en form av "HW Optical Flow Acceleration", men där saknas vissa "kernel-storlekar" som används av DLSS 3. Ampere har alla "kernel-storlekar" som Ada-har, men dels är råprestandan för låg och framförallt är latensen mellan "Tensor-kärnorna" (som utför alla DLSS 3 beräkningar asynkront mot CUDA-kärnorna) och CUDA-kärnorna (som behöver resultatet i slutändan) väsentligt högre pre-Ada.

Prestandakvoten (Tensor/CUDA) är därför 3-4 gånger högre hos Ada jämfört med motsvarande Ampere. Och är det i praktiken kvoten mellan GPUs övriga delar och Tensor-kärnorna som måste vara "tillräcklig". Även om 3090Ti har högre prestanda på sina Tensor-kärnor jämfört med t.ex. 3060, är det ungefär samma prestandakvot (Tensor/CUDA).

DLSS 3 / FSR 3 blir helt poänglöst om kostnaden att beräkna "mellanbilden" inte kan göras inom sin "dead-line" (precis som för dead-line schedulers är ett fel i algoritmen om dead-line missas, inte bara något som "ger sämre upplevelse").

Problemet/utmaningen för FSR 3 blir ju att beräkningarna kommer äta resurser från annat som också använder "de vanliga" grafikkärnorna (Tensor-kärnorna är separat från CUDA-kärnorna). Fördelen är att det fungerar på alla moderna GPUer.

TL;DR blir då i praktiken att pre-Ada saknar HW-stödet. Ampere kan fixa DLSS 3 i relativt låg upplösning om man också har relativt låg FPS. Men är ett sådan fall relevant?

FSR 2 åker på i alla spel det finns på för mig. Samma med DLSS när jag hade 3070. Även om det blir några artefakter och marginellt sämre estetiskt så är prestandavinsten allt för stor för att inte använda det. Så till vida jag inte kan köra 144FPS utan minsta drops, då skippar jag det. Med 3070 var det nästan ett krav då antingen VRAM tog slut på allt för många spel eller så orkade det helt enkelt inte med 1440P, skräpkort för 1440P. 60 FPS är inte ok.

> *Äger ett 3090*

Prestanda och uppfattad prestanda, spelar det verkligen någon roll (om det görs rätt)?

Om det kan göras perfekt, med noll artefakter, helt omärkbart, så är det ok. Innan den nivån uppnås så är det bara ett irriterande fluff, precis som interpoleringen som tv-apparater nuförtiden brukar vara fabriksinställda att göra, så man måste gräva i menyer för att hitta var man slår av skiten.

Om "noll artifakter" och perfektion är ett krav, då lär ju andra tekniker som Ambient Occlusion göra saker och ting ospelbart. Allehanda AA-tekniker lär även dessa försvinna (åtminstone allt bortom 2xMSAA+/DLAA). 3D-spel i allmänhet lär gå bort känner jag: shimmering, pop-ins och liknande kan grovt störa inlevelsen (perfekt exempel är Witcher 3 som lider av detta genomgående).

Interpolation är en sak och "fejkframes" är en annan.

Jag kan dock ej hålla med. Det finns inget som oäkta och äkta. Interpolation skapar perfekta frames så det är inte ens värt mödan att klaga på. Jag välkomnar det varmt. Ta en titt på SVP4 så förstår du vad jag menar. Många av dagens moderna TVn (OLED, QLED etc) har realtidsinterpolation som standard. Du får hålla dig till gamla TVn om du avskyr det så mycket.

Om du har en modern TV idag, t.ex. Samsung 65" QLED eller liknande så har du redan interpolationsteknik i den utan att du ens vet om det. Om då är fallet så har du tittat på en TV med interpolation och påstås veta om du ens märker det.
Jag märkte direkt med min nya TV att bilden flöt väldigt bra för att vara 24hz och att det inte enbart är rena "frames", varannan frame är interpolerad, och det mottagas tacksamt istället för att kalla det "fakeframes".

Det är väl ändå det första som stängs av när apparaten startas för första gången? Lite som att stänga av vivid och annat