AMD maakt FSR 4-broncode per ongeluk open source

AMD heeft de broncode van zijn FSR 4-technologie open source gemaakt. De broncode was op GPUOpen-GitHub verkrijgbaar onder de MIT-licentie in de FidelityFX SDK 2.0. Het bedrijf heeft de repository's inmiddels weer verwijderd.

Onder meer Videocardz schrijft dat sommige bestanden nog steeds toegankelijk zijn. Uit de broncode blijkt onder meer dat AMD werkte aan een INT8-versie voor FSR 4, waarmee de software beter zou moeten werken op RDNA 3-gpu's. Deze versie lijkt echter niet af en het is niet duidelijk of AMD de INT8-versie ook wilde uitbrengen of dat deze alleen intern werd getest.

AMD bevestigt aan hardwarejournalist Chips and Cheese dat het open source maken van de broncode 'een fout' was en dat de pagina's offline zijn gehaald. Gebruikers hebben echter al forks gemaakt en door de MIT-licentie mag de software gebruikt en gewijzigd worden, zowel voor persoonlijke als commerciële doeleinden. AMD heeft FSR 1, FSR 2 en FSR 3 al eerder open source gemaakt.

Reacties (39)

[Wouterie]

Wat zou eigenlijk het argument zijn om de drivers gesloten te houden? Het enige wat ik kan bedenken is dat er een partij geld aan probeert te verdienen... Maar hoe daar een markt voor zou kunnen zijn zie ik niet zo snel voor me.

[Some12]

Juridisch: tot code review.

[FreezeXJ]

Licensing, als je als spel FSR4 of soortgelijk wilt gebruiken moet je betalen. Daarnaast is NVidia ook druk bezig met fake frame algos bouwen, dus die kunnen wellicht ook wel wat ideeen gebruiken uit de nieuwe FSR.

Dat is ook waarom ze na X jaar alsnog open source worden, er is geen geld meer uit te halen, en de concurrentie is inmiddels ook al bij/verder. Daarnaast scheelt het onderhoud, nu kan de community er bugs uit halen, en de code verder optimaliseren. Dat zouden meer bedrijven moeten doen als hun code uit officiele support gaat.

[PjotrX]

Er zijn geen licentiekosten verbonden aan gebruik van FSR. Een reden om het closed source te houden is zodat het alleen op AMD hardware werkt. Ander reden is dat als het open source is men aangepaste versies in games gaat stoppen. Voor de games is dat soms goed want er kunnen optimizaties worden gedaan die anders onomgelijk zijn. Maar als het algorithme aangepast in een game is kan je het niet zo maar overriden met een nieuwe versie zoals dat bijvoorbeeld nu met DLSS kan. Je hebt namelijk kans dat dit artifacten gaat veroorzaken.

[Wolfos]

Nee, gameontwikkelaars passen FSR niet aan ook al is 3 open source, en ik denk ook niet dat Nvidia hier veel van kan leren.

Degene die wél aangepaste versies van FSR bouwt is ARM. Het zou goed kunnen dat AMD daar nog een deal mee hoopt te sluiten voor FSR4. Of met Qualcomm, of PowerVR. Die sector heeft best veel GPU ontwerpers.

[PjotrX]

FSR wordt zeker wel aangepast in games, kijk maar naar No Man's Sky Een aanpassing kan al heel klein zijn he, je kan bijvoorbeeld 1 van de passes overplaatsen naar een ander shader uit je engine omdat het beter is kwa VGPR allocatie etc. En bij ingewikkeldere algorithmen zoals FSR4 is er alleen maar meer mogelijkheid tot optimizatie. Zelfs de shader door de compiler heen halen met andere compiler-opties kan al genoeg zijn dat de driver moeite gaat hebben om de fsr-algorithme in de code op te sporen en te overriden. Met een .dll is vele malen deterministischer.

[Devil N]

Open source betekent ook dat developers de techniek kunnen porten naar platforms die anders niet ondersteund worden. FSR2 en FSR3 zijn al meermaals gebruikt in PS5 games, ondanks dat er geen officiële implementatie is voor de PlayStation's shader language.

Zo heb ik ook hoogstpersoonlijk FSR2 en FSR3's upscalers kunnen porten naar Unity, als in: de HLSL shaders laten compileren door Unity's eigen cross-platform shader compiler, en een nieuwe dispatch layer geschreven in C# tegen Unity's APIs. Daarmee was FSR ineens beschikbaar op praktisch alle platforms en graphics APIs die Unity kan targeten, inclusief mobile en consoles. Dat was alleen mogelijk dankzij AMD's besluit om hun techniek open source te maken.

[Arrigi]

Ik ben behoorlijk zeker dat DLSS/FSR/XeSS geheel gratis te gebruiken zijn. Elke vendor heeft er alleen maar voordeel bij, want die technologie werkt net goed op hun kaarten.

AMD had als kleinere speler dan weer een mogelijk extra voordeel bij het opensourcen zodat iedereen er mee kan doen wat ze willen om de ondersteuning/installed base extra te vergroten. Hun algoritme kan ook op elke GPU draaien, in tegenstelling tot DLSS.

Bij FSR4 blijft alvast het principe dat iedere partij het zo kan integreren. Er is een SDK en AMD zou niet liever hebben dan dat je game FSR4 ondersteunt. Op dit moment is dat met prebuilt DLLs, maar dus geen open source. Gezien het nu echt over een ML algoritme gaat en niet over "simpelere" berekeningen zoals in FSR1-3, is het nog de vraag of ze die nieuwe methode ook willen opensourcen.

DLSS is trouwens geheel closed-source, maar heeft alsnog een stevige install base.

[Blokker_1999]

Licensing kan ook in een andere vorm spelen. Als je zelf weer gebruik maakt van technologie die je onder licentie hebt, dan mag je ook niet zomaar de broncode daarvan openbaar maken zonder toestemming van de rechhebbende. Al weet ik niet of dat hier het geval zal zijn.

En daarnaast uiteraard ook gewoon bedrijfsgeheimen.

[rko4u]

als ik het goed begrijp, zijn de oudere versies open source en wordt aan deze versie nog hard aan ontwikkeld. Een reden zou kunnen zijn dat ze de code in ieder geval intern wilden houden tot het dev team klaar is met de code. Als je het open source zet zullen er namelijk pull requests komen die je allemaal moet reviewen. Dat kan tijdrovend worden wanneer je een half af systeem open source verklaart. In dat geval zou het vooral een ‘nog niet open source’ situatie zijn.

[Tk55]

Het is inderdaad een tijdrovend proces. Maar je kan prima je broncode openbaar maken zonder pull requests te accepteren. Dat gebeurt wel bij een aantal projecten. Dat scheelt je het werk van managen van de community en je kan blijven werken aan je eigen prioriteiten. Terwijl je wel je werk publiek deelt.

[StefanJanssen]

Totdat er hardware specifieke dingen instaan voor hardware die nog niet gereleased zijn.

[svenk91]

In aanvulling op @FreezeXJ, het kan zo zijn dat er nog stukken in de broncode zitten van andere partijen die niet openbaar gemaakt mogen worden. Stukjes code waar AMD zelf voor betaald heeft. Hier een alternatief stuk code voor schrijven dat wel openbaar mag kost soms wat tijd, om toch FSR4 snel uit te brengen hebben ze misschien tijdelijk wat externe expertise ingekocht.

[TheMak]

Als je de drivers open source naakt, maak je de concurrentie het wel heel makkelijk om het wiel opnieuw uit te vinden

[bzuidgeest]

De meest voorkomende reden in software en dus ook drivers zijn:

Techniek geheim willen houden.

Je hebt code van anderen in licentie genomen waarvan je niet het recht hebt die te publiceren.

[Halfscherp]

Deels om de secret sauce te beschermen, deels omdat er vaak 3rd party code inzit die je niet zomaar mag delen.

Vroegah waren de Nvidia drivers zoveel beter dan die van AMD omdat Nvidia per game enorm veel hacks / workarounds voor performance deed. Als ze hun driver open source hadden dan had AMD die simpelweg kunnen kopiëren.

[The Zep Man]

AMD heeft FSR 1, FSR 2 en FSR 3 al eerder opensource gemaakt.

Kan het zijn dat AMD uiteindelijk FSR 4 open source wil maken, maar dat ze dat per ongeluk te vroeg deden?

Ik weet van veel projecten die ooit commercieel/gesloten begonnen, dat het wat tijd kan kosten om de code "open source waardig" te maken. Zo moeten gesloten delen van derden verwijderd/vervangen worden, moet men een zekere hoogte van technical debt betalen, en natuurlijk ter afsluiting een controleslag voordat het wordt gepubliceerd. Het kan zijn dat een aantal voorbereidende stappen nog niet zijn uitgevoerd.

[Reactie gewijzigd door The Zep Man op 23 augustus 2025 11:37]

[Devil N]

Ik vermoed dat de open source release van FSR4 gewoon nog niet af was, maar dat ze iets moesten releasen tijdens Gamescom-week. Nu dus eerst een public release van de precompiled DLLs, wat al een grote winst is ten opzichte van de eerdere driver-based upgrade van FSR 3.1 waar AMD expliciet approval voor moest geven, en dan (hopelijk) later een volledige open source release met alle features die ze gepland hadden. Ze zijn duidelijk wel bezig geweest met een int8-implementatie om oudere kaarten te kunnen supporten, maar die is gezien de gelekte source nog niet volledig afgerond.

[William_H]

In het artikel staat dat FSR 1 t/m 3 wel open source zijn gemaakt, dus die gedachte is denk ik juist.

[djwice]

Een int8 versie zou heel mooi zijn, dat is namelijk wat de NPU in CoPilot+ laptops zeer energie efficient daaien met 45 TOPS of meer. Als frame generation op de NPU in plaats van op de GPU of CPU draait gebruikt de laptop een stuk minder stroom.

Dus zou dit zelfs soepel op de AMD CoPilot+ PC's kunnen gaan draaien zonder aparte grafische kaart.

[Reactie gewijzigd door djwice op 23 augustus 2025 11:39]

[Devil N]

FSR4 en die int8-implementatie gaan alleen maar over het upscaling-gedeelte. Het frame generation-gedeelte is nog steeds FSR 3, oftewel dezelfde compute shader-based code als voorheen die geen tensor cores of NPU vereist.

[justinkb]

Ik weet niet of jouw offload-naar-npu idee in de praktijk goed zou werken, want dan moet je alsnog al die te verwerken data meerdere keren kopiëren.

[djwice]

De CoPilot+ PC's maken gebruik van unified memory,; het RAM wordt daarbij gedeelte door de CPU, NPU en GPU en verwerkt typisch 8400MT/s met snelle toegangstijd.

Maar zoals Devil N in 'AMD maakt FSR 4-broncode per ongeluk open source' aangeeft had ik iets anders over het hoofd gezien: het gaat hier niet om de frame generatie maar om de upscaling.

[justinkb]

Ah, had in mijn hoofd een scenario met een Copilot+ pc met daarbovenop nog een dedicated high end gpu bijvoorbeeld.

[djwice]

Het mooie van die embedded memory systemen (zoals ook de M4 van Apple en de X Elite van Qualcomm) is dat de GPU en NPU typisch toegang heeft tot veel meer geheugen en dus grotere modellen kan draaien dan de meeste defeated GPU's.

Het nadeel is natuurlijk dat ze veel minder krachtig zijn.

Vergelijking: CoPilot+ ~ 50TOPS int8 maar bijvoorbeeld toegang tot 32 of 64GB geheugen. 5060TI/16GB ~ 750 TFlop fl4.

Dus de gtp-oss 20b (fl4) draait sneller op de NVIDIA hardware; veel modellen hebben niet standaard int8 kwantificering. Microsoft heeft op de CoPilot+ PC's een speciale versie van Phi die int8 gekwantificeerd is.

[yelop]

Hoop dat ze fsr 4 werkend krijgen voor mn ai max 395 APU. Want is wel lullig dat die apu's zo achterblijven.

[ApexAlpha]

HAhahaa, geniaal dit. Zou het expres zo 'per ongeluk' zijn gegaan door een medewerker?

In ieder geval goede dag voor open source drivers!

[closefuture]

Het feit dat die code heel kort als MIT licensed op Github stond en daarna verwijderd word maakt redelijk duidelijk dat het om een fout gaat. In een rechtzaal beargumenteren dat de code echt MIT licensed is ga je waarschijnlijk niet redden.

Daarbij als je gekeken hebt naar die source ben je wellicht wel "besmet" als je zou moeten uitleggen in een rechtzaak dat je echt niks van die code gekopieerd hebt in bijvoorbeeld een opensource driver. Want je hebt immers de "propiertary" broncode gezien.

[Reactie gewijzigd door closefuture op 23 augustus 2025 10:55]

[jaapzb]

Als het gewoon onder MIT op github stond is deze (versie van de) code in principe niet meer proprietair. Dan telt het "besmet zijn met proprietary code" dus ook niet meer. Of dat ook geld als een bedrijf zegt dat dat "per ongeluk" ging is denk ik een vraag die dan in de rechtbank uitgevochten moet worden.

Die MIT licentie zit er ook niet zomaar bij, die moet wel iemand bewust toegevoegd hebben aan de repo.

MIT is ook nog eens de beste licentie die ze er op konden zetten - vanuit het perspectief van andere open source ontwikkelaars gezien. Want die licentie zegt gewoon "kijk maar wat je er mee doet".

[Finraziel]

Dat hangt er vanaf of AMD het recht heeft om al die code opensource te maken denk ik. Als er iets in zit wat eigenlijk van een andere partij is, iets wat ze er nog uit zouden moeten halen voordat het opensource gemaakt kan worden, dan betekent deze fout van AMD natuurlijk niet dat die andere partij ook ineens niet achter je aan zou kunnen komen.

[The Zep Man]

Klopt. Wel kan de "gelekte" code gebruikt worden d.m.v. clean-room design om een variant te maken dat geen licentieproblemen heeft.

[Patriot]

Dat staat een beetje haaks op elkaar. Bij clean-room design wil je juist zo min mogelijk weten over de techniek die je concurrent gebruikt, de broncode van de oplossing van je 'tegenstander' bestuderen past daar totaal niet bij.

[The Zep Man]

Dat staat een beetje haaks op elkaar.

Niet echt. Lees het artikel. Een team stelt een specificatie op gebaseerd op gelekte broncode. Een juridisch team verifieert dat de specificaties geen auteursrechtelijk beschermd materiaal bevatten. Een volledig ander, onafhankelijk team gaat met de specificaties (zonder toegang tot de gelekte broncode) aan de slag om daar code mee te schrijven.

Dat beschermt tegen licentiegeneuzel (tried and tested), maar niet tegen patentclaims.

[Reactie gewijzigd door The Zep Man op 23 augustus 2025 12:38]

[i-chat]

Voor patentclaims kun je dan weer andere technieken inzetten

Pattenten kun je immers niet hebben op een idee alleen op een uitwerking

Bouw het idee na via een andete uitwerking en het patent is niet meet va toepassing


Let op dat een uitwerking wel iets meet omvat dan alleen de gecompileerde broncode

[William_H]

Ik denk dat dit de beste uitleg is waarom dit hele verhaal problematisch is. Eerdere versies van FSR die al open source zijn gemaakt, hebben waarschijnlijk die gesloten bron code verwijderd of zijn er aanpassingen gemaakt dat de code goed blijft functioneren zonder die gesloten code.

Het is uiteraard niet de schuld van de andere partijen die gesloten code hebben aangeboden aan AMD, dat AMD die ineens vrijgeeft. Uiteindelijk ligt die verantwoordelijkheid bij AMD, en kan die daarvoor nog een douw krijgen bij rechtzaken.

En inderdaad, ook de mensen die dit nu blijven verspreiden kunnen een douw krijgen, want de publiceert gesloten copyright code. Gezien het feit dat AMD de code heeft teruggetrokken, zegt genoeg.

[markjanssen]

Alleen als je die ook publiceerd.... zolang je die 'intern' voor eigen gebruik houd, zal dat niet zo snel een probleem zijn. Momenteel kan je de code nog makkelijk uit github trekken, dus mijn lokale mirror heeft natuurlijk ook een kopietje, net als vele repo's die nintendo heeft willen takedownen (of waarvan te verwachten is dat dit snel gebeurt).

[swampy]

Bedankt AMD

Dat is wel snel he! Nu ja FSR 4 Open Source, lekker.

[DarkSunshine]

Ben benieuwd wat modders ermee kunnen doen

[Jensw19]

Mooi pluspunt voor linux drivers. Gaat fijn geimplementeerd worden omdat sommige sowieso die MIT zien en denken letsgoo