Nvidia maakt DLSS-sdk beschikbaar voor Linux-ontwikkelaars

Nvidia heeft met een update voor de DLSS-sdk ondersteuning toegevoegd voor native x86-Linux-games. Daarnaast kondigt het bedrijf aan de techniek naar pc's met Arm-cpu's te willen brengen. DLSS werkte al op Linux via Steam Proton.

De ondersteuning voor native Linux-games zit in de sdk-versie 2.2.1, schrijft Nvidia. Met de native-ondersteuning kunnen ontwikkelaars zelf de Deep Learning Super Sampling-techniek implementeren in games. DLSS was al beschikbaar op Linux, maar dan alleen via Steam Proton. Proton is een opensourcetool van Valve waarmee Windows-games op Linux gespeeld kunnen worden. Een maand geleden kreeg deze tool ondersteuning voor DLSS, maar alleen via games die met de Vulkan-api werken. In de herfst volgt via Proton ondersteuning voor DirectX-games.

De sdk-update krijgt ook andere nieuwe functies, zoals de mogelijkheid voor ontwikkelaars om een sharpening slider toe te voegen aan games. Daarmee kunnen gamers het beeld scherper of juist minder scherp maken, afhankelijk van wat ze zelf willen. Ook is er een DLSS Auto Mode, die bij resoluties bepaalde kwaliteitsinstellingen gebruikt. Zo wordt bij 1440p of lager Quality ingesteld, bij 4k wordt Performance gebruikt en bij 8k wordt de DLSS-instelling op Ultra Performance gezet.

De laatste nieuwe functie is een auto-exposure-instelling. Deze instelling berekent automatisch de belichtingswaardes voor ontwikkelaars en laat ontwikkelaars de beeldkwaliteit van scènes met een lager contrast verbeteren.

DLSS is een reconstructietechniek van Nvidia die de Tensor-cores van GeForce RTX-videokaarten gebruikt. De techniek rendert games in een lagere resolutie en schaalt ze weer op naar hogere resoluties. Machinelearning vult de ontbrekende details in. Met DLSS kunnen gamers zonder veel kwaliteitsverlies hogere framerates genereren.

Maandag demonstreerde Nvidia ook de werking van RTX-raytracing en DLSS op een Chromebook met een Arm-cpu van MediaTek, gecombineerd met een RTX 3060-gpu. Daarvoor gebruikte Nvidia een aangepaste versie van Wolfenstein: Youngblood.

Reacties (61)

[cricque]

Tsja, het zou mooi zijn, Linux native games, maar de markt is spijtig genoeg te verspreid, veel te veel mogelijkheden, desktop omgevingen, package systemen. Vroeger wel bijvoorbeeld eerst begonnen met Return to Castle Wolfenstein op linux met wine te spelen, haalde meer fps dan onder windows trouwens. Nadien kwam er een linux native client uit, was wel leuk. Maar dat waren ook opengl games. Hoezeer ik graag ook de AAA titels zou spelen op Linux (native) ik blijf gewoon wel effe dual booten. Enja ik gebruik al linux sinds 97-98. Misschien proton toch nog eens proberen. Maar voor battle.net (blizzard games) updates, ja daar is altijd wel wat mee. Althans vroeger toch.
Het is natuurlijk mooi dat dit er komt, maar de vraag is als je kijkt naar "de linux markt", dan is dat een heel klein deel. Hoeveel van die mensen zullen er effectief een game kopen of spelen ... Dat krijg je niet verkocht in een groot bedrijf, de mogelijke winst is veel te klein voor de effort. Of ze moeten het echt zien als marketing stunt. Als de echte grote game engines linux ook native zouden ondersteunen (ik dacht wel dat ze dat reeds deden, maar kan verkeerd zijn) dan is er misschien toekomst. Maar als proton werkt, waarom zou iemand dan nog de moeite doen om native linux games te maken. De reactie bij management zal dan dikwijls zijn "ze kunnen maar spelen via proton, voor die enkelingen, en halen ze wat minder fps, dan moeten ze settings maar wat lager zetten of betere videokaart kopen". Dat is de bedrijfswereld, het moet opbrengen. En dat zie ik spijtig genoeg niet gebeuren

[rbr320]

Het grootste deel van je verhaal klopt wat mij betreft, de Linux desktop markt is inderdaad klein en zal door de grote game studio's waarschijnlijk te klein geacht worden om het rendabel te maken om een "native" versie van hun games voor uit te brengen. Echter, kunnen we stoppen met het benoemen van verschillen in desktop omgeving, package management, kernel versies en andere "versplintering" als oorzaken waarom het zogenaamd lastig zou zijn om een native applicatie/game voor Linux te maken? Dat is namelijk gewoon klinkklare onzin.

Verder zijn er in de afgelopen anderhalf jaar grote stappen gemaakt met betrekking tot gaming op Linux. Proton (wat is gebaseerd op Wine) werkt goed, ook voor AAA-games en wordt steeds beter. Grote AAA single-player games werken tegenwoordig een paar weken na release gewoon onder Linux via Steam. Dat is niet zo gek want Valve zet hier met de aankondiging van hun Steam Deck volledig op in.

Do I need to port my game to Linux to have it work on Steam Deck?
No porting necessary. Your Windows build will likely work right out of the box, thanks to Proton.

De grootste hindernissen zijn nog copy-protection/DRM en online anti-cheat, maar ook daar wordt hard aan gewerkt.

Persoonlijk hoop ik natuurlijk dat met het uitkomen van de Steam Deck de penetratie van Linux als gaming OS omhoog gaat, wat hopelijk zal leiden tot meer native games op Linux zodra de ontwikkelaars in gaan zien dat Wine/Proton eigenlijk maar een lapmiddel is.

edit: wat betreft Blizzard games en Battle.net, daarvoor gebruik ik Lutris. Onder water gebruikt deze ook weer Wine of Proton om je Windows games te draaien, maar het haalt het beheer daarvan weg bij de gebruiker die gewoon een spelletje wil spelen. Ik heb eigenlijk nooit problemen meer met battle.net, maar mijn ervaring is dan ook beperkt tot Starcraft 2 en Heroes of the Storm.

[Reactie gewijzigd door rbr320 op 26 juli 2024 15:07]

[Morzzz]

Precies dit. Developers kunnen gewoon de meest populaire distro targetten en de rest van de Linux wereld regelt wel dat het in de repositories terecht komt. In het geval van bijvoorbeeld Arch Linux is men niet anders gewend dat bestaande binary packages (rpm/deb) of generic installers (run) uit elkaar worden getrokken en daarvan een package wordt gemaakt. Dat wordt gedaan door de community, daar hoeft een developer helemaal niet mee bezig te zijn.

[rbr320]

Klopt. Als jij een distro draait met een redelijk recente Linux kernel en je overige libraries redelijk up-to-date zijn dan draait de meeste user-space software, inclusief games, gewoon zonder problemen. Als de software zonder broncode als binair pakket buiten het package management proces om wordt aangeboden is het aan te raden om de wat meer exotische libraries mee te bundelen of gebruik te maken van een standaard set die door je distributie kanaal wordt aangeboden, zoals de Steam Linux Runtime.

Ik snap niet waarom men hier bij Linux altijd zo moeilijk over doet, terwijl dit proces vrijwel gelijk is aan hoe het onder Windows werkt met 3rd party software.

[MSalters]

Daar is een heel zwikje redenen voor. Een AAA game is uiteraard een "binair pakket, zonder broncode, buiten het package management proces om", dus de moelijke categorie.

Windows heeft dan de reputatie om veel groter te zijn, maar dat komt omdat er veel meer standaard geïnstalleerd is, terwijl je voor Linux de "wat meer exotische libraries" moet bundelen bij je binair pakket. En vervolgens heb je dan weer het probleem dat die gebundelde libraries geen libc dependency kunnen hebben, want dat is onder Linux niet gestandaardiseerd. De C library zou maar 3 smaken hoeven te hebben: C89, C99 en C11, want dat zijn de 3 ISO standaarden, maar Linux heeft niet-portable eigen extensies.

[Hydranet]

Steam is bezig met developers om bepaalde Anti-Cheats werkende te krijgen via proton.

My game uses anti-cheat, which currently doesn’t work with Proton - how do I get around this for Steam Deck?
We’re working with BattlEye and EAC to get support for Proton ahead of launch.

[D0phoofd]

Het is inderdaad hoog tijd dat je Proton eens gaat proberen. Er zijn zelfs games waarbij, zelfs in Proton, meer FPS behaald word dan onder Windows. [1] Artikel is al uit 2019 overigens.

Het gaat niet zo zeer om of het Native is. Het gaat er meer om of er open protocollen gebruikt worden die goed te implementeren zijn. Vulkan is daar het zwaargewicht. Ook in combinatie met 'dxvk' (DirectX to Vulkan). Iedereen heeft daar baat bij. Zowel Xbox, Playstation, Windows, Linux. Nu Mac OS nog (die gebruiken Metal). Dan is er niet meer zo veel 'verspreid' zoals je denkt dat het is.

[1] https://www.forbes.com/si...x-gaming-performance/amp/

[rbr320]

Goed artikel, met name de laatste alinea deed bij mij wel even een glimlach ontstaan.

Het artikel is inderdaad alweer (vrijwel exact) 2 jaar oud en in die tijd is er wederom een hoop verbeterd. We zijn 4 versies van Pop!_OS verder en de ontwikkelingen aan Proton, DXVK en de open source graphics drivers van AMD hebben niet stil gestaan. Ik draai zelf thuis Pop!_OS en alle games die ik speel lopen soepel, waar dat een paar jaar geleden nog wel eens wat te wensen over liet.

[!GN!T!ON]

De manier waarop ze auto-tiling hebben gedaan ziet er erg gelikt uit. Ik gebruik nu Arch met I3, misschien dit eens een poging geven.

[!GN!T!ON]

Ik zou voor mijn game-pc graag overstappen, maar even een snelle check op protondb en van de vijf spellen die ik regelmatig met vrienden speel is er 1 bronze met issues, 2 draaien helemaal niet (o.a. Warzone), 1 silver en eentje gold.

Maakt mij nogal huiverig en geen warzone is eigenlijk gewoon een dealbreaker a.t.m.

[CAPSLOCK2000]

Hoezeer ik graag ook de AAA titels zou spelen op Linux (native) ik blijf gewoon wel effe dual booten. Enja ik gebruik al linux sinds 97-98. Misschien proton toch nog eens proberen.

Je reactie is (gelukkig ) een beetje gedateerd. Er zijn best wel veel AAA titels die ofwel out-of-the-box werken ofwel via Proton. Ik wil niet beweren dat alle games werken of dat er nooit bugs zijn want dat kan ik bij Windows ook niet beloven. En misschien kost het een beetje performance, maar wat ik over hou is meer dan genoeg voor mij, en ik heb geen bijzondere hardware. Misschien dat het beter of meer zou werken onder Windows maar eerlijk gezegd is dat voor mij niet de juiste vraag, er is geen enkel platform dat alle games kan spelen. De juiste vraag is dus: "Kan ik genoeg leuke games spelen?".

Het is natuurlijk mooi dat dit er komt, maar de vraag is als je kijkt naar "de linux markt", dan is dat een heel klein deel. Hoeveel van die mensen zullen er effectief een game kopen of spelen ... Dat krijg je niet verkocht in een groot bedrijf, de mogelijke winst is veel te klein voor de effort. Of ze moeten het echt zien als marketing stunt.

De meeste bedrijven hoeven eigenlijk niks extra's te doen. Ze kunnen hun bestaande software gewoon as-is aan Linux-gebruikers verkopen via Proton. Sommige game-engines (zoals Unity) kunnen ook native Linux versies produceren met nauwelijks extra moeite. Zeker als je game toch al gebouwd is voor meerdere platformen (pc, xbox, playstation).
Het zijn gewoon een miljoen extra klanten om je software aan te verkopen. Dat zijn er een stuk minder dan Windows maar het blijft een aanzienlijke markt.

Voor de klanten is het ook een risicoloze investering om "Linux" games te kopen want Steam-licenties zijn niet aan een platform gebonden. Je raakt je games dus niet kwijt als je van platform wisselt.

Als de echte grote game engines linux ook native zouden ondersteunen (ik dacht wel dat ze dat reeds deden, maar kan verkeerd zijn) dan is er misschien toekomst. Maar als proton werkt, waarom zou iemand dan nog de moeite doen om native linux games te maken.

Vanwege:
1. De cloud. De hele softwaremarkt beweegt zich richting de cloud en software-as-a-service. De games-markt is er ook al mee aan het experimenteren. Niemand weet of en wanneer de doorbraak komt, maar je kan er maar beter rekening mee houden.
De cloud draait op Linux dus lijkt het een goed idee om te zorgen dat je games goed werken onder Linux.
2. Standaard hardware. Valve/Steam timmert al een tijdje aan de weg met eigen hardware. Van Steam Machine tot Index tot Steam Deck. Als Steam Deck aanslaat dan zou dat het eerste PC-platform met gestandariseerde hardware zijn. Standaard hardware maakt het makkelijker om een game te optimaliseren omdat je de hardware goed kent.
3. Onafhankelijkheid. Er is een enorme machtsstrijd gaande rond software-distributie. In het kort komt het neer op de vraag of Microsoft de Windows App store net zo dominant kan maken als de appstores van Android en Apple. Dat zou natuurlijk het einde zijn voor Steam als appstore, dus dat Valve dat niet wil is een open deur. Maar voor de schrijvers van games/applicaties is het ook geen fijne gedachte dat ze zo enorm afhankelijk zijn van die appstores. Niet alleen heb je eigenlijk niks te kiezen dan het accepteren van alle eisen, voorwaardes en prijzen van zo'n appstore, maar je wil je bedrijf ook niet zo afhankelijk maken. Als zo'n appstore je om wat voor reden dan ook afsluit dan kun je je bedrijf wel sluiten. Dusver houden Valve en Microsoft elkaar eerlijk. Geen van beide kan grote veranderingen of prijsverhogingen doorvoeren zonder klanten weg te jagen naar de andere partij toe. Maar dat werkt alleen zolang het geloofwaardig is dat de ander de hele markt over neemt als de een steken laat vallen.
Ook daarom kan het verstandig zijn om te zorgen dat je software niet helemaal afhankelijk is van 1 platform zodat je, als het echt moet, een alternatief hebt.

[rbr320]

Ik wilde ook nog even reageren op

Als de echte grote game engines linux ook native zouden ondersteunen (ik dacht wel dat ze dat reeds deden, maar kan verkeerd zijn)

maar wilde niet mijn andere post weer aanpassen. Helaas is dit niet het geval. De enige grote bekende game engine waarbij ik nog een beetje het gevoel heb dat Linux een first class citizen is, is Unity3D. Er zijn wel een aantal kleinere game-engines die volledig naar Linux zijn geport of al vanaf het begin ook voor Linux zijn ontwikkeld, maar die worden slechts binnen een studio gebruikt. Van de engines die door grote studio's worden gebruikt voor hun triple-A games ondersteund er voor zover ik weet niet een Linux. Amazon Lumberyard heeft naar verluid Linux ondersteuning, maar daar hoor je eigenlijk nog weinig over.

EPIC heeft destijds bij het uitbrengen van de Unreal Engine 4 veel bombarie gemaakt over dat ze Linux zouden gaan ondersteunen. Daar is echter weinig van terecht gekomen. Veel van het Linux-specifieke werk aan de engine is gedaan door de community, wat mogelijk is aangezien de broncode van UE4 gewoon beschikbaar is. De meeste van de tools om de engine heen zijn echter nooit voor Linux beschikbaar gekomen, dus ontwikkelen op Linux zit er met UE4 niet in. Daarnaast moet je als spelontwikkelaar natuurlijk wel moeite doen om een goede build te maken van je game client voor Linux, wat nog niet zo eenvoudig lijkt. De enige game waar ik ervaring mee heb op dat gebied is ARK en hoewel de Linux client prima functioneert, ziet de wereld er een stuk beter uit als je de Windows client gebruikt. Ik speel dit spel dan ook via Proton tegenwoordig, voor zover ik het nog speel.

rant: Tim Sweeney van EPIC heeft rond het uitkomen van UE4 heel hard geroepen dat hij gaming op Linux net zo belangrijk vond als Valve dat vond en vindt. Die uitspraken zijn inmiddels al een paar jaar behoorlijk hol gebleken en bij de aankondiging van Unreal Engine 5 is er met geen woord over Linux gerept. Die man heeft binnen de Linux gaming community inmiddels behoorlijk afgedaan.

[Reactie gewijzigd door rbr320 op 26 juli 2024 15:07]

[Magic Power]

Ik heb vroeger in Linux, Windows spellen geprobeerd te spelen via Wine. Erg succesvol was dat inderdaad niet, want er werkte te veel niet, en je moest bij meerdere spellen alles goed instellen om het te laten werken. Toendertijd (voor 2017) gebruikte je gewoon Windows als je spellen wilde spelen. Dat deed ik ook.

Nu (na 2018, en zeker in 2021) is de situatie echt heel erg anders. Dankzij Steam, Proton en Lutris heb je nu de situatie dat de meerderheid van de Windows spellen niet alleen waarschijnlijk gewoon werken onder Linux, maar ook nog eens zeer makkelijk te installeren zijn. Steam+Proton onder Linux is het grootste effect daarvan: De meeste spellen kun je gewoon installeren en spelen door te muisklikken op 'Install', en als het geïnstalleerd is op 'Play' te klikken, precies zoals je dat ook in Windows zou doen. De performance ligt heel dicht tegen native Windows performance aan, en het werkt grotendeels gewoon, zonder problemen.

En voor alle non-Steam spellen kun je Lutris gebruiken. Dit is een app waar je non-Steam Windows-games mee kunt installeren, met bijna hetzelfde gemak als via Steam. Voor zaken als Uplay en Battle.net e.d. kun je je spel selecteren, klik je op install, en wordt alles voor je geïnstalleerd en geconfigureerd, inclusief de desbetreffende launchers. En voor spellen zonder een store geef je aan waar de .EXE staat om het spel mee te installeren. De rest wordt automatisch gedaan door Lutris. Op dit moment heb ik met Lutris: Far Cry 3 (Uplay), Far Cry 5 (Uplay), Supreme Commander FA (CD/EXE) en Gruntz (DOS,EXE) allemaal gewoon werkend zonder problemen.

Spellen spelen kan in 2021 heel goed met Linux. Daarom kan Valve nu de Steam Deck uitbrengen die draait op Linux, omdat de tijd en techniek er nu rijp voor is.

[CaineTanathos]

Ter info Diablo 3 werkt perfect via wine 🙂

[ErwinPeters]

Waarom niet gewoon kvm met die product id masking techniek waar men laatst hier over publiceerde?

[winwiz]

Antwoord op FSR om zo veel mogelijk terrein te winnen?

[Pep7777]

Weet ik niet dat is toch vooral een appels met peren vergelijken verhaal.

FSR gebruikt vergelijkbare namen als DLSS2 om de indruk te krijgen te ze evenveel fps winnen, voor de rest zijn het gewoon andere technieken met andere kwaliteit. Persoonlijk vind ik FSR er (nog) niet beter uitzien dan DLSS2.

Wat FSR natuurlijk wel interessant maakt is dat het op meer hardware draait en ontwikkelaars dus minder versies van de software hoeven te maken testen.

Met andere woorden ze hebben allebij hun voors en tegens.

[mjtdevries]

FSR hoeft er toch ook niet beter uit te zien?
Dat is een vreemde redenatie. Zonder extra hardware vergelijkbare kwaliteit zou al een hele prestatie zijn.

Bij de recente hardware unboxed vergelijking is het duidelijk dat bij hoge resoluties FSR en DLSS ondanks dat ze totaal andere technieken hebben, in de praktijk vergelijkbare performance en kwaliteit halen. (Als je op 300% zoom moet kijken om verschillen te zien, dan is er geen discussie mogelijk dat de kwaliteit heel dicht bij elkaar ligt)
Allebei dus mooie technieken voor de consument.

DLSS doet het beter op lage resoluties, maar deze technieken gebruik je nu juist om hogere resoluties te kunnen gebruiken.

[Pep7777]

Zeker mooie technieken

Maar dan moeten ze beeld niet slechter maken als je niet upscaled, en dat deed (doet) FSR wel in elite dangerous odysey veel te veel edge enhancment (sharpening filter).

[mjtdevries]

In alle situaties word op een lagere resolutie gerenderd. Daar komt de prestatie winst vandaan. dus per definitie is er altijd een upscaling, maar daarnaast ook een sharpening filter en nog meer.
Bij die hardware unboxed video zie je ook dat op ultra quality er teveel sharpening word toegepast, terwijl quality het op een juist niveau heeft.
Overigens vraag ik me af hoeveel mensen het op zal vallen, want dat is ongeveer wat iedere TV in Nederland al minimaal aan overmatige scharpening ingesteld heeft staan.
Uiteindelijk krijg je die extra prestatie natuurlijk niet gratis. En je mag wel verwachten dat Elite één van de worst case scenarios is, waarin de truukjes die gebruikt worden negatief opvallen.

[winwiz]

Het gaat mij er ook niet om wat beter, sneller, mooier is. Wat wel een feit is is dat FSR blijkbaar (veel) makkelijker geïmplementeerd kan worden en wat je niet wilt is dat een duur ontwikkeld systeem ondersneeuwt.

[Pep7777]

Ja FSR schijnt makkelijker te implementeren te zijn, je hoeft het als ik het goed begrepen heb niet te "trainen" omdat het geen AI/Neuraal netwerk is.

[mjtdevries]

Ik zou wel eens willen weten hoeveel trainen er voor beide nu werkelijk nodig is.
Als je bv denkt aan het feit dat DLSS van voorgaande beelden gebruik kan maken. Dat zou toch geen training nodig hebben?

Zou de training niet vooral zijn: controleer waar er lelijke artefacten zijn en vertel FSR of DLSS van die gedeelten af te blijven?

[Pep7777]

FSR heeft geen training nodig, en werkt ook maar op 1 beeld tegelijk.
DLSS werkt ook met "vorige beelden" (en kan dus motiontracking/voorspelling doen) en heeft wel training nodig. Er word frame voor frame een game op hoge resolutie gerendered (16K!) gerendered en op lage resolutie en wordt de AI geleerd bij deze lager resolutie hoort eigenlijk die resolutie.

Ieder game heeft toch zo zijn eigen grafische eigenschappen zoals bijvoorbeeld wel of geen hekwerk (rasters) en de AI leert dat dan zo goed mogelijk te upscalen.
Dus nee training kijkt niet naar specifiek lelijke/moeilijke (veel detail) stukken maar echt naar volledige reeksen (in tijd) van specifieke game beelden

[mjtdevries]

FSR heeft geen training nodig, en werkt ook maar op 1 beeld tegelijk.

Als FSR geen training nodig zou hebben, dan had AMD er gewoon een optie van kunnen maken in hun drivers, ipv dat developers het specifiek zelf beschikbaar moeten maken in hun games.

En je geeft geen antwoord op mijn vraag. Juist motiontracking zou geen training nodig hebben omdat je de extra informatie uit de voorgaande beelden kan gebruiken. Zonder die informatie zou je moeten gokken en daar heb je dan training voor nodig om een goede gok te maken. Maar dat hoeft dus niet omdat je die voorgaande info hebt.

AMD en Nvidia maken er mooie PR praatjes omheen, maar de resultaten zouden anders zijn als hun verhalen kloppen. Bv dat 16K rendering verhaal. Als je die AI leert welke hoge resolutie bij de lage resolutie hoort, dan zou je best case scenarios moeten hebben waarbij het niet uitmaakt welke performance mode je kiest, in alle situaties krijg je dezelfde hoge resolutie terug. Maar in de praktijk zien we dat niet.

In de praktijk leveren FSR en DLSS vergelijkbare prestaties en beeldkwaliteit. Hoe wil jij verklaren dat het verschil zo minimaal is, terwijl DLSS kan profiteren van de extra informatie van de vorige beelden en (volgens jou) alleen DLSS kan profiteren van de training.
Volgens die redenatie zou DLSS altijd veel beter moeten presteren. Maar in de praktijk blijkt dat niet zo te zijn. Dat is niet op een logische manier te verklaren op basis van jouw argumenten.

[Pep7777]

Sorry als ik je geen antwoord heb gegeven, Ik doe mijn best.

FSR is geen simpele driver update omdat je als ontwikkelaar het moet toevoegen aan je game.
Ergens na het renderen van de 3d beelden voeg je FSR toe en pas daarna moet je alle 2D elementen toevoegen zoals HUD's en menus anders worden deze ook ge-upscaled en dus fuzzy.
Niet heel moeilijk maar dus wel een codeer stapje.

Nog even een linkje opgezocht:
https://www.hardwaretimes...ison-which-one-is-better/

[mjtdevries]

Als je er vanuit gaat dat dat het enige codeer stapje is dat nodig is, dan mogen we verwachten dat vanaf nu elk nieuw spel FSR support zal hebben.

Dat linkje is verder vrij nutteloos omdat die een appels en peren vergelijking doet op basis van de paar screenshots die AMD in hun aankondiging gaf en een verkeerde interpretatie van de informatie.

De test van Hardware Unboxed waarbij DLSS en FSR in dezelfde applicatie getest word op dezelfde Nvidia GPU is veel nuttiger. En dan blijkt er vrijwel geen kwaliteit en geen performance verschil te zijn.
Uiteindelijk is de praktijk situatie het enige dat echt telt.

Wat nog een interessante gedacht kan zijn, is hoeveel Nvidia hun DLSS zou kunnen verbeteren door gebruik te maken van de code van AMD.
Zoals ik al eerder zei heeft de Nvidia kaart meer informatie tot zijn beschikking dan FSR gebruikt. Als FSR zonder die informatie al gelijkwaardige kwaliteit als DLSS haalt, hoeveel kan Nvidia dan nog verbeteren door bovenop FSR de extra info van DLSS toe te voegen?
En anders moeten we tot de conclusie komen dat de hardware implementatie van DLSS voornamelijk een truuk was om mensen nieuwe kaarten te laten kopen. Dat is natuurlijk een beproeft truukje van Nvidia.

[Alxndr]

FSR is nog geen maand uit...

[Simyager]

Inderdaad ja. Moet wel zeggen dat allebei de technieken veel beloven voor de toekomst. Het werd iets te stil op de gaming markt. Ray-tracing vond ik zelf nou niet echt heel veel toevoegen, maar DLSS en FSR brengen echt de verbetering die we nodig hadden.

[Alxndr]

idd raytracing is veel betalen voor bijna onzichtbare verbetering, met deze technieken krijg je gewoon een prestatie verbetering alsof je overstapt naar een volgende generatie. Helemaal fantastisch dat FSR ook op (oude) Nvidia kaarten werkt.

Ik kom er nu achter dat GTA V ook onofficieel ondersteund wordt - als ik tijd heb toch eens kijken wat voor effect dat op mijn GTX 1060 @3440*1440 heeft.

[pascalnederland]

Jij vind dat mischien ! maar Raytracing met Dlss op een LG OLed 120 hz met warzone ziet er dus wel fantastisch uit.

Met een 1060 kom je niet ver nee ! die ondersteund niet hardwarematig raytracing :-)

draai met een 3080 en het ziet er allemaal top uit.

[Reactie gewijzigd door pascalnederland op 26 juli 2024 15:07]

[Alxndr]

Mijn 4 jaar oude video kaart ondersteund geen raytracing? Echt waar, meen je dat?!

Ik heb zelf idd geen ervaring met RT, maar op basis van reviews van oa Linus en Jayz2cents durf ik in twijfel te trekken of jij het verschil kunt zien tussen RT aan en uit in een blinde test zou kunnen zien, aangezien het zelfs professionele reviewers vaker niet dan wel lukt.

Dat het er op jouw 3080 met een OLED scherm fantastisch uit ziet wil ik best geloven, als ik dat had zou ik RT ook zeker proberen. Maar de vraag is uiteindelijk wat je persoonlijke voorkeur is, hogere resolutie/hogere FPS/hogere settings... en vooral wat het je waard is.

Er moet een boel in mijn leven veranderen voordat ik een videokaart van meer dan 400 of 500 euro z'n geld waard vind.

[pascalnederland]

klopt ik wil alles gewoon netjes hebben en zeker op zo`n 65 inch Oled.

[Jack77]

Mmm, persoonlijk vind ik RTX technologieën wel degelijk een meerwaarde. En bedoel ik vooral global illumination en ray-traced shadows dat scenes er veel natuurlijker laat uitzien. En reflections kunnen ook iets toevoegen. In Control schrok ik me bvb. rot toen ik om een hoek kwam en op mijn eigen reflectie in glas afliep.

Dat gezegd zijnde denk ik dat we nog minstens 1 hardware generatie verwijderd zijn van voldoende performantie. Alles onder een 3070 in in mijn ogen te licht om het meer dan een showcase te maken.

[Reactie gewijzigd door Jack77 op 26 juli 2024 15:07]

[pascalnederland]

Daarom....

[watercoolertje]

Tot nu toe heb ik net zo veel games kunnen spelen met DLSS als met FSR, precies 0 (oke 0.5 voor DLSS want die ene dag dat cyberpunk heb gespeeld heb ik wel 2 sec geprobeerd).

Maargoed daar ging het toch ook niet om, het gaat om het gemak van implementeren en dus potentie naar de toekomst, niet wat de huidige staat is van iets wat 24 maanden tegenover 1 maand op de markt is...

[Reactie gewijzigd door watercoolertje op 26 juli 2024 15:07]

[Umbrah]

Dat gaat een uitdaging zijn in dezelfde lijn als dat GSync/Freesync (aka VESA Adaptive Sync) een uitdaging was waarvoor nVidia op den duur niks anders kon dan het integreren: FSR is 100% open gemaakt en aan de community gegeven, kan elke engine in gezet worden, en op elke GPU draaien. Het is niet zo ingrijpend als: "dit zit in elke monitor, TV en smartphone VS er is een nVidia module nodig in de monitor", maar desalniettemin ingrijpend: voor DLSS moet er werk gedaan worden, FSR werkt altijd al.

En dan komt er weer een VHS/BetaMax verhaal: Betamax was beter -- VHS won.

[Jack77]

DLSS werkt niet zonder de tensor cores op de RTX videokaarten.

[Anoniem: 159816]

Hoe kom je daarbij? FSR en DLSS2 zijn geen concurrenten. Het zijn twee compleet verschillende technieken.

[winwiz]

Als je een huis maakt van bakstenen of een huis van 3d geprint beton. Totaal verschillende technieken met als doel een huis bouwen. Lijken me toch wel concurrenten. FSR en DLSS2 hebben toch als doel een hogere FPS met zo min mogelijk kwaliteitsverlies om het even heel in het kort te verwoorden.

[Iblies]

Euhhh….

DLSS2 mag je eerder vergelijken met een sporadische sportwagen en FSR eerder met de gewone volkswagen en vergelijkbaar.

Maandag demonstreerde Nvidia ook de werking van RTX-raytracing en DLSS op een Chromebook met een Arm-cpu van MediaTek, gecombineerd met een RTX 3060-gpu. Daarvoor gebruikte Nvidia een aangepaste versie van Wolfenstein: Youngblood.

Met name dat dikgedrukte maakt het een groot circus. DLSS zit op dit moment op de (extreem) dure kaarten, wat voor clownseke actie is het om een chromebook te “ondersteunen” met een gpu die waarschijnlijk duurder is. Dat Nvidia de planning heeft om het langzaam naar beneden te gaan werken geloof ik wel, maar daar zit een langere termijn aan vast wat ik niet zo snel zie gebeuren, helemaal niet met de huidige capaciteiten mbt cpu-productie.

FSR is een kwestie van opnieuw programmeren. Zelfs Intel is geïnteresseerd in de techniek omdat hun kaarten in de regel minder presteren.
Het opnieuw programmeren kan er ook (hopelijk) ook toe leiden dat ontwikkelaars opnieuw naar hun software kijken. Als je met een “mindere” kaart veel meer spelervaring kunt leveren is dat win-win. En de laatste jaren zie je dat mobiel extreem veel winsten heeft gemaakt met games die wat simpeler zijn en op heel veel platformen kunnen draaien.

Het pad dat Nvidia kiest met nog meer “precisie” is al redelijk achterhaald. Dat wordt steeds meer niche. Ervaring en beleving komen weer meer naar voren simpelweg omdat je op kleine schermen al die details sws niet ziet.

[MSalters]

NVidia heeft al jarenlang eigen ARM CPU's met geïntegreerde GPU's (zoals de Jetson). Het in aannemelijk genoeg dat DLSS ook op de volgende generatie daarvan komt. Dan is een voorproefje met een externe GPU niet zo'n gek idee. Uiteraard kan de prijs dalen bij integratie, en scheelt het ook weer in de benodigde productiecapaciteit.

[Anoniem: 159816]

Ja, en dan regent het en is je huis weg. Daarom is het geen vergelijking. Het is net alsof je zegt dat de nieuwe BMW M5 een reactie is op de Fiat 500 Abarth.

[winwiz]

Grapjas.... https://www.rtlnieuws.nl/...-eindhoven-printen-huizen
Ontopic: Het verschil tussen FSR enDLSS in hoge resoluties en hoge kwaliteit is bijna niet te onderscheiden volgens de laatste testen.

[Alxndr]

Klinkt alsof je zegt dat benzine en diesel motoren geen concurrenten zijn omdat de technieken verschillen.

Dat de ene meer vermogen en de andere meer koppel heeft, prima, aan het einde van het verhaal laten beide gewoon iets draaien.

[Anoniem: 159816]

Diesel en benzine zijn directe concurrenten, dit niet. Dit is een vergelijking tussen een auto op stoom en een auto op benzine/diesel. Ja, ze bewegen beiden de auto voort, maar er zit een enorm gat in de prestaties. NVIDIA maakt zich echt nul zorgen over FSR.

[SirNobax]

Volgens mij gaat het gros in de comments compleet voorbij het feit dat DLSS een anti-aliasing methode is die ook met een lagere render scale werkt, terwijl FSR enkel upscaling doet, zonder ook maar iets qua anti-aliasing te doen.

FSR is in feite weinig meer dan een realtime lanczos upscaler (zoals we allemaal uit fotosoep kennen) i.c.m. contrast-based sharpening:

The FSR component makes two passes—upscaling, and sharpening. We learn from the source code that the upscaler is based on the Lanczos algorithm, which was invented in 1979. Media PC enthusiasts will know Lanczos from MadVR, which has offered various movie upscaling algorithms in the past. AMD's implementation of Lanczos-2 is different than the original—it skips the expensive sin(), rcp() and sqrt() instructions and implements them in a faster way. AMD also added additional logic to avoid the ringing effects that are often observed on images processed with Lanczos.

Aldus TPU.

[Anoniem: 159816]

FSR werkt sowieso alleen maar met data van de huidige frame. Het is in feite MadVR voor games .

[mjtdevries]

Diesel en benzine zijn directe concurrenten, dit niet. Dit is een vergelijking tussen een auto op stoom en een auto op benzine/diesel. Ja, ze bewegen beiden de auto voort, maar er zit een enorm gat in de prestaties.

Zo denken de Nvidia fanboys er dus over.
Dan de werkelijkheid.: https://www.youtube.com/watch?v=zDJxBykV1C0
Op de settings waarvoor DLSS en FSR ontwikkeld zijn: kunnen spelen op hoge resolutie en hoge beeldkwaliteit, leveren beide oplossingen vergelijkbare prestaties en vergelijkbare beeldkwaliteit.

Er is een enorm gat ja. Maar dat enorme gat zit tussen jouw beweringen en de werkelijkheid.

[pascalnederland]

Ze hebben al meer terrein ?

[Oon]

Over het algemeen kun je stellen dat Nvidia altijd eerder is, maar AMD meteen open source gaat of hun technologie zo veel mogelijk verspreidt, wat dan weer tot een hogere baseline leidt voor de hele markt.

Dus ik denk dat Nvidia inderdaad nu gezien heeft dat AMD dichtbij komt, en deze keuze heeft gemaakt om mensen binnen Nvidia te houden. Want waar AMD's technologie t.z.t. misschien ook wel op Nvidia-kaarten zou kunnen draaien, zou Nvidia dat nooit toestaan met hun eigen implementatie.

[Wolfos]

Als je een kaart koopt heb je daar helemaal niks aan. Feit is dat er nu twee jaar aan games zijn die DLSS en RTX implementaties hebben, en dus beter werken op Nvidia.
Er komen nog steeds games uit die alleen ray tracing ondersteunen op Nvidia kaarten.

[GarBaGe]

Wat het niet eens tijd voor wat meer adaptieve kwaliteit.
Je geeft een gewenste framerate en resolutie op, en de game / de driver gaat proberen deze zoveel mogelijk te matchen.
Framerate te hoog? > meer kwaliteit!
Framerate te laag? > kwaliteit terugschroeven.
Dit kan dan ook icm met DLSS.
Native 4K net te zwaar?, hop terug naar 1440p en met DLSS naar 4K

[Wolfos]

Unity heeft zoiets:
https://blog.unity.com/te...with-adaptive-performance

Maar vooralsnog alleen voor Samsung telefoons. De applicatie moet namelijk weten of het de CPU of de GPU is die de lag veroorzaakt om specifieke instellingen aan te passen.
Op consoles word er veel van dynamische resolutie gebruik gemaakt, maar dan weet je ook waar de bottleneck ligt.

[lilmonkey]

Er zijn overigens ook gewoon games die dit op PC prima implementeren, zoals Gears 4, AC Valhalla, Warframe, ME Andromeda, Titanfall 2 en natuurlijk Quake II RTX

[lilmonkey]

Dit. Gelukkig komen er langzaam aan steeds meer PC games die dit ondersteunen, maar het mag wel wat sneller gaan. Geen idee waarom dit niet gewoon al lang standaard een optie is, de techniek is niet nieuw.

[mjtdevries]

In de AMD driver zit een optie "Radeon Boost"
Dat verlaagt dan automatisch de resolutie als de framerate te laag word.
https://www.amd.com/en/support/kb/faq/dh3-033
Ik heb het zelf nog nooit gebruikt en ik heb niet de indruk dat je veel details kunt instellen, maar het idee is er dus al wel.

[lilmonkey]

Jep. Helaas is Boost een zeer ongelukkige implementatie, want het werkt op basis van muisbeweging, niet FPS. Het werkt dus niet wanneer je de muis niet beweegt (WASD-movement bijvoorbeeld), maar doet wél z'n ding wanneer je met de muis in een menu bezig bent ( ). En tot overmaat van ramp doet Boost dus ook z'n magie wanneer je FPS torenhoog is. Tot slot weet Boost dus ook niet hoeveel de performance geoptimaliseerd moet worden — hoe meer je de muis beweegt, hoe meer Boost optimaliseert.

Ik kan me voorstellen dat het in zeer specifieke gevallen uitkomst kan bieden, maar dit is wat mij betreft toch echt een grote misser van AMD. Nou ja, ze hebben hiervoor gewoon http://www.hialgo.com/home.html overgenomen en het in de driver gegooid (en het compatibel gemaakt met DX11/DX12).

[mjtdevries]

hmm, dat is inderdaad niet handig.

Nou ja, ik denk dat ik wel begrijp waarom. Hun concept is waarschijnlijk dat je dan de resolutie kan verlagen zonder dat het opvalt. Als je beeld zo snel beweegt kun je toch scherpte niet goed waarnemen.
Bewegingen met WASD zijn veel minder snel en dan zou een lagere resolutie wel opvallen.

Maar dan is hun doel dus anders dan wat wij willen. Wij willen de kwaliteit omlaag als de framerate te laag word, ook als dat betekent dat je dat duidelijk kunt zien. Framerate heeft hogere prio dan kwaliteit in dat geval.

En dan is Boost inderdaad niet de oplossing.

[Jack77]

The heat is on.
En daarnaast is het interessant voor Nvidia om te tonen dat RT en DLSS ook op ARM kan, voor console-doeleinden.

EDIT: hierboven worden ook Apple, en cloud-systemen aangehaald, waarvoor deze show-case/evolutie ook nuttig kan zijn.

[Reactie gewijzigd door Jack77 op 26 juli 2024 15:07]