Computerphile förklarar Nvidia DLSS och uppskalning via neurala nätverk

Trädvy Permalänk
Pattern Juggler
Registrerad
Dec 1999

Computerphile förklarar Nvidia DLSS och uppskalning via neurala nätverk

Uppskalning via Nvidia DLSS är på tapeten efter lansering i två stora speltitlar. Ett videoklipp på Youtube-kanalen Computerphile går igenom konceptet från ett tekniskt perspektiv.

Läs hela artikeln här

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa leder till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Trädvy Permalänk
Medlem
Plats
Jönköping
Registrerad
Okt 2011

Fy vad najs! Älskar Mike Pound, alla videor med honom är så underhållande. Och lärorika såklart

Trädvy Permalänk
Medlem
Registrerad
Okt 2011

Här är en idé, lite "out there" jag vet men försök att hänga med:
Hur skulle det vara om man plockade bort det döda kislet (tensor cores) och ersatte det med helt vanliga ROP's !
Och vem vet vi kanske t.o.m. skulle kunna slänga in en 512-bit minnesbus när vi ändå håller på för att få specsen att matcha priset !

Och är det inte lite lustigt hur svårt det verkar att få fram vad "DL" delen verkligen innefattar ?
Om det är din egen hårdvara som förbättrar sig själv för vissa spel, var tar den datan vägen ?
Och vem äger den datan ?
Är det däremot spelföretagen som utnyttjar din hårdvara, kommer du att få ersättning för detta jobb ?

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011

Fortfarande rätt oklart om DLSS kommer visa sig vara en bra teknik som tillför något eller om det i slutändan bara visade sig vara varmluft från Nvidias PR-maskineri.

DLSS imponerande inte precis vid lansering av Metro Exodus, men här verkar det ju rätt mycket som det var rena buggar givet hur enormt mycket bättre det blev efter första patchen som kom en vecka efter release.

Själv har jag funderat lite varför man inte använder checkerboard rendering (CBR) i stället för något som DLSS. Efter lite sökningar på nätet finns det ett par förklaringar.

  • som Computerphile nämner är en stor fördel med machine-learning att tiden att hantera en scen är helt konstant oavsett indata. Det är inte fallet för CBR utan där varierar kostnaden med t.ex. hur mycket olika objekt rör sig mellan scener

  • största problemet med CBR är att det blivit ett minfält av patent . DLSS bygger på "supervised machine-learning", en teknik som är helt öppen (DLSS är dock allt annat än öppet då det kräver träning i Nvidias datacenter)

  • DLSS är en ren "post-processing" teknik, d.v.s. det är enkelt att lägga till i en existerande spelmotor, även väldigt sent i processen. Detta gör också att DLSS är enkelt att ha som en valbar option. CBR kräver betydligt djupare integration i spelmotorn, vilket gör tekniken svårare att ha som något valbart och det är dyrare för speltillverkarna att lägga till tekniken

  • ingen direkt fördel för oss kunder, men DLSS kräver ju att någon upplåter datacenterkraft för att utföra träningen. För Nvidias del kan de ju "bjuda" på den tjänsten då träningskravet binder tekniken till deras GPUer, något som gör att Nvidia kan "bjuda" spelutvecklarna på kostnaden för att integrera DLSS i spel

Något som Computerphile nämner och som är en viktigt del i DLSS delen av tekniken är att man tränar nätverket på scener som är renderande med x64 super-sampling.

Så även om det handlar om uppskalning är det egentligen bara x64 super sampling som är omöjligt att passera. Är i teorin möjligt för DLSS att ta något <4k och ge ett resultat som är bättre än "äkta" 4k utan super-sampling. Om det någonsin kommer hända i praktiken är en annan fråga, ju mindre "typiska" scenerna i ett spel är ju lägre är den sannolikheten.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Sep 2010
Skrivet av Svensktiger:

Här är en idé, lite "out there" jag vet men försök att hänga med:
Hur skulle det vara om man plockade bort det döda kislet (tensor cores) och ersatte det med helt vanliga ROP's !
Och vem vet vi kanske t.o.m. skulle kunna slänga in en 512-bit minnesbus när vi ändå håller på för att få specsen att matcha priset !

Och är det inte lite lustigt hur svårt det verkar att få fram vad "DL" delen verkligen innefattar ?
Om det är din egen hårdvara som förbättrar sig själv för vissa spel, var tar den datan vägen ?
Och vem äger den datan ?
Är det däremot spelföretagen som utnyttjar din hårdvara, kommer du att få ersättning för detta jobb ?

Döda kislet? De behövs ju för FP16/INT8/4 osv, som ju är relevant med spel som Wolfenstein. Sen så kanske de ger upp DLSS framöver, det är inte så jävla lätt implementera tydligen som nVidia hävdade och inte speciellt imponerande heller.

Trädvy Permalänk
Hedersmedlem
Plats
Malmö
Registrerad
Apr 2007
Skrivet av Svensktiger:

Här är en idé, lite "out there" jag vet men försök att hänga med:
Hur skulle det vara om man plockade bort det döda kislet (tensor cores) och ersatte det med helt vanliga ROP's !

Nu är det väl inte riktigt dött. Men visst hade det lett till mer spelprestanda i nuvarande generation grafikkort. Yes. Jag hade haft mer glädje av en sådan ändring också
Tanken här är väl att bana väg för att kunna förbättra grafiken på nya kreativa sätt. Än så länge är vi väl inte riktigt där, men det kommer säkerligen förbättringar på tekniken.

Skrivet av Svensktiger:

Om det är din egen hårdvara som förbättrar sig själv för vissa spel,

Nope. Utvecklingen och förbättringen av tekniken samt grunden för vad som ska göras sköts i nvidias serverhallar. Där tas ett viktnings och texturpaket fram vilket är hela grunden. Det ens eget grafikkort sedan gör är att tillämpa det här specialpaketet, men någon självförbättring av tekniken sker ej hos konsument. Detta förklaras i videon också ;).

Skrivet av Svensktiger:

var tar den datan vägen ?

Datapaketen som är anpassade per spel för att DLSS ska fungera skickas ut med nvidias drivrutiner. I nuläget funkar det men när stödet för spel blir bredare får man nog tänka om så att uppdateringarna inte blir allt för stora. Säkerligen inte så svårt att lösa ;).

Skrivet av Svensktiger:

Och vem äger den datan ?

Nvidia. De har tagit fram datan i serverhallarna.

Skrivet av Svensktiger:

Är det däremot spelföretagen som utnyttjar din hårdvara, kommer du att få ersättning för detta jobb ?

Njää. Troligen finns inte mycket att hämta där hehe. Vi väljer själva vad vi vill spela och det är väl upp till oss själva om vi vill belasta våra grafikkort med spel.

🖥 → Ryzen 5 2600@4,1ghz • Gainward RTX 2070 • 16GB DDR4 • MSI B450I Gaming Plus AC (mITX)
💻 → SurfacePro 3 [i5 • 4GB ddr3 • keybaord + pen]
🖱 → Corsair m65 white / ⌨ → pok3r nordic white
📱 → Oneplus6
🎧 → Sennheiser momentum wireless & Logitech g930

Trädvy Permalänk
Hedersmedlem
Plats
Malmö
Registrerad
Apr 2007
Skrivet av Yoshman:

Något som Computerphile nämner och som är en viktigt del i DLSS delen av tekniken är att man tränar nätverket på scener som är renderande med x64 super-sampling.

Så även om det handlar om uppskalning är det egentligen bara x64 super sampling som är omöjligt att passera. Är i teorin möjligt för DLSS att ta något <4k och ge ett resultat som är bättre än "äkta" 4k utan super-sampling. Om det någonsin kommer hända i praktiken är en annan fråga, ju mindre "typiska" scenerna i ett spel är ju lägre är den sannolikheten.

Jag tänkte på den delen också. Frågan är väl vad nvidia egentligen hittar på "serverside". En möjlighet är kanske att de också kör ännu högre upplösning än 4K när de förbereder dlss för upplösningen 4K som ska köras när man då spelar.
Om så är fallet så kan det kanske hända andra grejer också. But who knows

🖥 → Ryzen 5 2600@4,1ghz • Gainward RTX 2070 • 16GB DDR4 • MSI B450I Gaming Plus AC (mITX)
💻 → SurfacePro 3 [i5 • 4GB ddr3 • keybaord + pen]
🖱 → Corsair m65 white / ⌨ → pok3r nordic white
📱 → Oneplus6
🎧 → Sennheiser momentum wireless & Logitech g930

Trädvy Permalänk
Medlem
Registrerad
Mar 2017
Skrivet av scara:

Döda kislet? De behövs ju för FP16/INT8/4 osv, som ju är relevant med spel som Wolfenstein. Sen så kanske de ger upp DLSS framöver, det är inte så jävla lätt implementera tydligen som nVidia hävdade och inte speciellt imponerande heller.

Wolfenstein kör inget på tensor cores. Är dock inte säker på om den utnyttjar FP16 alls för Turing, har inte hört talas om det. Om den använder FP16 så är det på vanliga cuda cores (1660Ti har ju trots allt 2x FP16, utan tensor cores!). Den stora prestandaförbättringen som ses i Wolfenstein 2 från DOOM (ca 20% om jag minns rätt) kommer från att de kör compute accelererad culling, som liknar Mesh Shaders som är nytt till Turing. Detta utöver att de kör heltal och flyttal parallellt. Svårt att säga hur mycket som kommer från var.

Men man kan fundera på: Om det är så fantastiskt, varför tog de bort de där ~10-15% av SM-arean till 16xx serien? Speciellt när den hade , enligt deras utsago, passat bäst när FPS är låg som det brukar vara för de mindre kraftfulla korten? Kanske kom de fram till att det inte var kostnadseffektivt på gamingkort? ¯\_(ツ)_/¯

Trädvy Permalänk
Medlem
Plats
Hudiksvall
Registrerad
Mar 2012

denna youtube kanal följer man sen minst 2år tillbaka.
hela kanalen är en bra kanal, för att förstå säkerhet och hur vissa saker funkar och är uppbyggda.
som kryptering och programmering också vidare... man gillar deras sett dom gör det på i kanalen jämt..

Chassi: In Win , GPU: 3st sapphire radeon r9 290 4gb "kylare på gpu:na är corsiar hg10a1 å h75" ,HDD:arna: samsung ssd 840 pro 256gb 1st 1tb, 3st 2TB, 1st 3tb WD (rpm 7200) Ram: Corsair vengeance 32GB (4x8192MB) CL10 1866hz, Moderkort: gigabyte 990fxa-ud5, CPU: Amd fx 8350 black edition, CPU Kylare: crosair H100i,  PSU: corsair 1500w 80c guld ( Im Music Producer. Vibrations Is God Sound )

Trädvy Permalänk
Medlem
Plats
gbg
Registrerad
Nov 2007

tänk om de lagt till mer prestanda (shaders o skit) istf att slösa kretsyta/tid på den här skiten

i7 4770 | asus b85m-g | 4x4gb ddr3 1600 corsair/g.skill | asus gtx 1070 strix | intel 320 120gb + kingston a400 480gb + samsung f1 750gb | corsair vx450 | tr true black | fractal r3 | lg w2363d 120hz | dt 880 | win 10 x64 | deathadder chroma | qck+ | tb impact 600

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Sep 2010
Skrivet av Radolov:

Wolfenstein kör inget på tensor cores. Är dock inte säker på om den utnyttjar FP16 alls för Turing, har inte hört talas om det. Om den använder FP16 så är det på vanliga cuda cores (1660Ti har ju trots allt 2x FP16, utan tensor cores!). Den stora prestandaförbättringen som ses i Wolfenstein 2 från DOOM (ca 20% om jag minns rätt) kommer från att de kör compute accelererad culling, som liknar Mesh Shaders som är nytt till Turing. Detta utöver att de kör heltal och flyttal parallellt. Svårt att säga hur mycket som kommer från var.

Wolfenstein 2 och Far Cry 5 utnyttjar FP16....
Kanske inte på Tensor Cores. I AI-beräkningar används Tensor-croes företrädesvis, vet inte vad skillnaden är i spel.

Skrivet av Radolov:

Men man kan fundera på: Om det är så fantastiskt, varför tog de bort de där ~10-15% av SM-arean till 16xx serien? Speciellt när den hade , enligt deras utsago, passat bäst när FPS är låg som det brukar vara för de mindre kraftfulla korten? Kanske kom de fram till att det inte var kostnadseffektivt på gamingkort? ¯\_(ツ)_/¯

Vet inte vad det här har med min inlägg alls att göra.

Trädvy Permalänk
Medlem
Plats
Arvidsjaur
Registrerad
Jul 2001
Skrivet av jH0Ni:

Fy vad najs! Älskar Mike Pound, alla videor med honom är så underhållande. Och lärorika såklart

Att se alla avsnitt av Computerphile med just Mike Pound borde vara obligatoriskt för samtliga på SweC. Frivilligt men rekomenderat är också Steve Bagley, Phil Moriarty och David Brailsford.

| ASUS Z87M-Plus | Intel Core i5-4670K | Corsair Vengeance DDR3 PC12800 CL10 LP 4x8GB | ZOTAC GeForce GTX 1080 AMP! Extreme | Corsair HX650 650W PSU | Creative SoundBlaster Z | Samsung 830 256GB SSD | Samsung 850 EVO 500GB | Wester Digital Green 1TB HDD | ASUS BC-12D1ST BD-ROM | Dell 3011WFP (2560x1600) | Win10 Home | Bahnhof 100/100 |

Trädvy Permalänk
Medlem
Registrerad
Mar 2017
Skrivet av scara:

Wolfenstein 2 och Far Cry 5 utnyttjar FP16....
Kanske inte på Tensor Cores. I AI-beräkningar används Tensor-croes företrädesvis, vet inte vad skillnaden är i spel.

AMD var de som implementerade det. Med shader intrinsics så måste de ha separata kodvägar för att det ska fungera på andra kort (Vega & Polaris kör andra shaders). T.ex if(Vega || Polaris) vs if(fp16_support) . Hur kan man då vara säker på att de gjort FP16 tillgängligt för andra kort än Vega (som är det enda kortet från AMD som drar nytta av det, samt att det är AMD som implementerat det)?

Eller så kan man anta att AMD är snälla och supportar det genom D3D11_FEATURE_SHADER_MIN_PRECISION_SUPPORT , eller vad motsvarande är för Vulkan. AMD har mig veterligen inte påstått något annat än att dessa spel använder FP16 för Vega. Men om någon kan bevisa att FP16 verkligen används i de två spelen på 1660Ti eller Turing så är jag redo att tro det.

Men, när jag letade runt efter FP16 instruktioner och Turing kom det upp ny info (släpptes igår!) som inte finns jag inte kan hitta i deras whitepaper jag läst igenom. Kommer du ihåg att jag sa att 1660Ti har 2x FP16 på samma sätt som Turingkorten har 2x FP16 och således antog jag att denna funktionalitet fanns i deras CUDA cores, eftersom de inte hade nämnt något annat? Det är lite mer komplicerat än så tydligen att de bara tog bort RT och Tensor cores, de har även ersatt dem med *trumvirvel* FP16 cores. Och de berättade även hur Turing får 2x FP16 :

The Curious Case of FP16: Tensor Cores vs. Dedicated Cores

Even though Turing-based video cards have been out for over 5 months now, every now and then I’m still learning something new about the architecture. And today is one of those days.

Something that escaped my attention with the original TU102 GPU and the RTX 2080 Ti was that for Turing, NVIDIA changed how standard FP16 operations were handled. Rather than processing it through their FP32 CUDA cores, as was the case for GP100 Pascal and GV100 Volta, NVIDIA instead started routing FP16 operations through their tensor cores.

The tensor cores are of course FP16 specialists, and while sending standard (non-tensor) FP16 operations through them is major overkill, it’s certainly a valid route to take with the architecture. In the case of the Turing architecture, this route offers a very specific perk: it means that NVIDIA can dual-issue FP16 operations with either FP32 operations or INT32 operations, essentially giving the warp scheduler a third option for keeping the SM partition busy. Note that this doesn’t really do anything extra for FP16 performance – it’s still 2x FP32 performance – but it gives NVIDIA some additional flexibility.

Of course, as we just discussed, the Turing Minor does away with the tensor cores in order to allow for a learner GPU. So what happens to FP16 operations? As it turns out, NVIDIA has introduced dedicated FP16 cores!

These FP16 cores are brand new to Turing Minor, and have not appeared in any past NVIDIA GPU architecture. Their purpose is functionally the same as running FP16 operations through the tensor cores on Turing Major: to allow NVIDIA to dual-issue FP16 operations alongside FP32 or INT32 operations within each SM partition. And because they are just FP16 cores, they are quite small. NVIDIA isn’t giving specifics, but going by throughput alone they should be a fraction of the size of the tensor cores they replace.

To users and developers this shouldn’t make a difference – CUDA and other APIs abstract this and FP16 operations are simply executed wherever the GPU architecture intends for them to go – so this is all very transparent. But it’s a neat insight into how NVIDiA has optimized Turing Minor for die size while retaining the basic execution flow of the architecture.

Now the bigger question in my mind: why is it so important to NVIDIA to be able to dual-issue FP32 and FP16 operations, such that they’re willing to dedicate die space to fixed FP16 cores? Are they expecting these operations to be frequently used together within a thread? Or is it just a matter of execution ports and routing? But that is a question we’ll have to save for another day.

Från anandtechs 1660Ti recension så berättar de var Turings FP16 prestanda kommer från

Så tydligen får man reda på efter 5 månader att FP16 kan köras parallellt på tensor cores samtidigt som CUDA cores är aktiva (OBS! I vanliga fall är tensor cores i ett sådant tillstånd att CUDA och RT cores inte kan användas, t.ex under DLSS. Detta har gjort dem mer "post process"-aktiga för att de inte ska störa alltför mycket, men det stämmer uppenbarligen inte alltid). De har inte varit så tydliga att med Turing så tar FP16 instruktioner en helt annan väg än tidigare och går genom tensor cores parallellt med de andra kärnorna. Kort sagt så verkar de tagit bort möjligheten till DLSS och andra tensor operationer för att ersätta dem med bara 2x FP16. Vilket gör mig ännu mer förvirrad. Enda anledningen jag kan tänka mig är att de förväntar sig att FP16 ska användas mycket mer när Navi släpps.

NVIDIA PR har slagit sig i huvudet. Istället för att lyfta fram DLSS så kunde de ha lyft fram 2x FP16 prestanda behöver tensor cores, de hade setts från ett annat perspektiv. Jag kan dock konstatera att tensor cores tjänar ett syfte även om man inte använder t.ex DLSS.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Sep 2010
Skrivet av Radolov:

AMD var de som implementerade det. Med shader intrinsics så måste de ha separata kodvägar för att det ska fungera på andra kort (Vega & Polaris kör andra shaders). T.ex if(Vega || Polaris) vs if(fp16_support) . Hur kan man då vara säker på att de gjort FP16 tillgängligt för andra kort än Vega (som är det enda kortet från AMD som drar nytta av det, samt att det är AMD som implementerat det)?

Eller så kan man anta att AMD är snälla och supportar det genom D3D11_FEATURE_SHADER_MIN_PRECISION_SUPPORT , eller vad motsvarande är för Vulkan. AMD har mig veterligen inte påstått något annat än att dessa spel använder FP16 för Vega. Men om någon kan bevisa att FP16 verkligen används i de två spelen på 1660Ti eller Turing så är jag redo att tro det.

Men, när jag letade runt efter FP16 instruktioner och Turing kom det upp ny info (släpptes igår!) som inte finns jag inte kan hitta i deras whitepaper jag läst igenom. Kommer du ihåg att jag sa att 1660Ti har 2x FP16 på samma sätt som Turingkorten har 2x FP16 och således antog jag att denna funktionalitet fanns i deras CUDA cores, eftersom de inte hade nämnt något annat? Det är lite mer komplicerat än så tydligen att de bara tog bort RT och Tensor cores, de har även ersatt dem med *trumvirvel* FP16 cores. Och de berättade även hur Turing får 2x FP16 :

The Curious Case of FP16: Tensor Cores vs. Dedicated Cores

Even though Turing-based video cards have been out for over 5 months now, every now and then I’m still learning something new about the architecture. And today is one of those days.

Something that escaped my attention with the original TU102 GPU and the RTX 2080 Ti was that for Turing, NVIDIA changed how standard FP16 operations were handled. Rather than processing it through their FP32 CUDA cores, as was the case for GP100 Pascal and GV100 Volta, NVIDIA instead started routing FP16 operations through their tensor cores.

The tensor cores are of course FP16 specialists, and while sending standard (non-tensor) FP16 operations through them is major overkill, it’s certainly a valid route to take with the architecture. In the case of the Turing architecture, this route offers a very specific perk: it means that NVIDIA can dual-issue FP16 operations with either FP32 operations or INT32 operations, essentially giving the warp scheduler a third option for keeping the SM partition busy. Note that this doesn’t really do anything extra for FP16 performance – it’s still 2x FP32 performance – but it gives NVIDIA some additional flexibility.

Of course, as we just discussed, the Turing Minor does away with the tensor cores in order to allow for a learner GPU. So what happens to FP16 operations? As it turns out, NVIDIA has introduced dedicated FP16 cores!

These FP16 cores are brand new to Turing Minor, and have not appeared in any past NVIDIA GPU architecture. Their purpose is functionally the same as running FP16 operations through the tensor cores on Turing Major: to allow NVIDIA to dual-issue FP16 operations alongside FP32 or INT32 operations within each SM partition. And because they are just FP16 cores, they are quite small. NVIDIA isn’t giving specifics, but going by throughput alone they should be a fraction of the size of the tensor cores they replace.

To users and developers this shouldn’t make a difference – CUDA and other APIs abstract this and FP16 operations are simply executed wherever the GPU architecture intends for them to go – so this is all very transparent. But it’s a neat insight into how NVIDiA has optimized Turing Minor for die size while retaining the basic execution flow of the architecture.

Now the bigger question in my mind: why is it so important to NVIDIA to be able to dual-issue FP32 and FP16 operations, such that they’re willing to dedicate die space to fixed FP16 cores? Are they expecting these operations to be frequently used together within a thread? Or is it just a matter of execution ports and routing? But that is a question we’ll have to save for another day.

Från anandtechs 1660Ti recension så berättar de var Turings FP16 prestanda kommer från

Så tydligen får man reda på efter 5 månader att FP16 kan köras parallellt på tensor cores samtidigt som CUDA cores är aktiva (OBS! I vanliga fall är tensor cores i ett sådant tillstånd att CUDA och RT cores inte kan användas, t.ex under DLSS. Detta har gjort dem mer "post process"-aktiga för att de inte ska störa alltför mycket, men det stämmer uppenbarligen inte alltid). De har inte varit så tydliga att med Turing så tar FP16 instruktioner en helt annan väg än tidigare och går genom tensor cores parallellt med de andra kärnorna. Kort sagt så verkar de tagit bort möjligheten till DLSS och andra tensor operationer för att ersätta dem med bara 2x FP16. Vilket gör mig ännu mer förvirrad. Enda anledningen jag kan tänka mig är att de förväntar sig att FP16 ska användas mycket mer när Navi släpps.

NVIDIA PR har slagit sig i huvudet. Istället för att lyfta fram DLSS så kunde de ha lyft fram 2x FP16 prestanda behöver tensor cores, de hade setts från ett annat perspektiv. Jag kan dock konstatera att tensor cores tjänar ett syfte även om man inte använder t.ex DLSS.

Ok tack för info!

Trädvy Permalänk
Medlem
Plats
Mälardalen
Registrerad
Dec 2012

Nu är det sent på kvällen och orkar inte leta upp referenser till det jag påstår på rak arm ... men:

DLSS för mig är en teknik som är bra på att få upp bildkvalitet ELLER/OCH prestanda på statiska scener. Tänk direkt här på alla scenarion det träffar - nästan alla som techtubers, benchmarks och liknande testar. (inte en bild, snarare en hel loop med bilder) Sen tränar de scenerna i deras datacenter och får till bra approximationer, skickar ut det som rekommendationer vid specifika scenarion.. helt hemskt lågt. Kommer se bra ut på alla recensioner och benchmarks - ingen vettig vinst i normala spel där det är oförutsägbart vad som inträffar.

Många initiala tester har jämför det med att spela spelet på en lägre - dock - uppskalad upplösning för att vinna prestanda - därav smöret eller vaselinet som spills över skärmen.

Vi är långt bort idag från att ha den här typen av "pre-calculation" av alla dessa scenarion. Inte ens streamingtjänsterna för spel kommer att nå mycket längre på många år. (om det kommer streamingstjänster till de stora konsolerna så finns det en potential för att förarbeta vissa scener etc. Exemel på det kan tänkas vara saker som är gemensamma mellan 500 miljoner spelare går lätt att vinna prestanda eller bildkvalitet på)

Vill gärna att redaktionen håller ett öga öppet för skillnader mellan "normala benchmarking scener" och helt oanvända. Många gör det enkelt (inget konstigt med det) för sig. Kommer eventuellt att bli intressant.

[1700X] [B350 mITX] [16GB DDR4@3200MHz] [Vega 56] [Nano S] [D15S] [Win 10 Pro]

Trädvy Permalänk
Medlem
Plats
Sundsvall
Registrerad
Okt 2003

Den stora frågan för mig är om, och i så fall hur mycket, bättre DLSS är jämfört med bildskärmens inbyggda uppskalningsalgoritm?
Någon som testat att bara köra BF5 i fullskärm med lägre upplösning för att kolla skillnaden?

För övrigt anser jag att MS FlightSim X borde vara standard som ett av benchmarkprogrammen.

Trädvy Permalänk
Hedersmedlem
Plats
Malmö
Registrerad
Apr 2007
Skrivet av Olle P:

Den stora frågan för mig är om, och i så fall hur mycket, bättre DLSS är jämfört med bildskärmens inbyggda uppskalningsalgoritm?
Någon som testat att bara köra BF5 i fullskärm med lägre upplösning för att kolla skillnaden?

Yes. Det har testats. Eller ja, jag vet inte om de kanske istället låter grafikkortet skala ner upplösningen till de ovanliga upplösningarna som testas, men det innehåller iaf jämförelser mot uppskalat material.
Hardware unboxed är tämligen kritiska till DLSS. Vet inte om det verkligen är så illa, men det ser ut som att de har en poäng.

🖥 → Ryzen 5 2600@4,1ghz • Gainward RTX 2070 • 16GB DDR4 • MSI B450I Gaming Plus AC (mITX)
💻 → SurfacePro 3 [i5 • 4GB ddr3 • keybaord + pen]
🖱 → Corsair m65 white / ⌨ → pok3r nordic white
📱 → Oneplus6
🎧 → Sennheiser momentum wireless & Logitech g930