Intel brengt bètadriver uit met Retro Scaling voor Ice Lake-gpu's

Intel heeft een gpu-driver uitgebracht die de functie Retro Scaling toevoegt. Dat is de naam die Intel geeft aan integer scaling, wat de weergave van games met pixelart of een lage resolutie moet verbeteren.

De Retro Scaling-fuctie is vooralsnog alleen beschikbaar in bètadriver 25.20.100.7155 en werkt alleen voor de gpu's van Ice Lake-processors. Dat betekent in de praktijk dat weinig mensen er gebruik van kunnen maken, er zijn nog nauwelijks producten met Ice Lake-processors op de markt. De nieuwste variant van de Dell XPS 13 2-in-1 is momenteel de enige laptop die te koop is en een Ice Lake-processor heeft.

Om integer scaling te gebruiken moet Retro Scaling in het Intel Graphics Command Center aangezet worden. Daarbij is er keuze uit Scaled Width of Fixed Width. Bij laatstgenoemde optie worden pixels zonder verdere interpolatie opgeschaald. Een oude game met een resolutie van 1024x768 pixels kan daarmee bijvoorbeeld op 2048x1536 pixels weergegeven worden op een monitor met een resolutie van 3840x2160 pixels. Iedere pixel wordt dan vier keer getoond, maar er zullen ook zwarte balken aanwezig zijn.

Bij Scaled Width wordt de volledige schermhoogte gebruikt, resulterende in een beeld van 2880x2160 pixels op diezelfde 4k-monitor. Daarbij wordt wel gebruikgemaakt van nearest neigbour-interpolatie, waarbij ontbrekende pixels ingevuld worden aan de hand van de vier omliggende pixels.

Intel beloofde al in juli dat er ondersteuning voor integer scaling naar de gpu-driver komt en gaf toen ook uitleg en voorbeelden van de functionaliteit. Wanneer de functie beschikbaar komt voor de geïntegreerde gpu's van andere Intel-processors is nog niet bekend. Nvidia bracht eind augustus een driver uit voor zijn RTX- en GTX 16xx-videokaarten met daarin ondersteuning voor integer scaling.

Reacties (28)

[koelpasta]

Het verhaal over 'scaled width' in het artiekel lijkt niet te kloppen.
De genoemde resolutie(s) en het plaatje suggereren dat het hele beeld geschaald wordt en niet enkel de breedte.
In het rechter plaatje is zowel breedte als hoogte niet-integer geschaald en vallen de zijkanten zomaar weg. De breedte wordt dus niet nog extra geschaald.

In emu-land betekent 'scaled width' ook iets heel anders, namelijk het corrigeren voor niet-vierkante pixels. Het probleem is namelijk dat de pixel aspect ratio van (met name) oude TV's anders is dan van een huidige computermonitor.
Maar dat is totaal niet wat we in de plaatjes zien.

Dus wat bedoelen ze bij intel dan precies met dat 'scaled width'?

Daarbij wordt wel gebruikgemaakt van nearest neigbour-interpolatie, waarbij ontbrekende pixels ingevuld worden aan de hand van de vier omliggende pixels.

Dit klopt volgens mij niet. In 2D wordt bij nearest neighbor niet gekeken naar de vier omliggende pixels (er zijn overigens 8 omliggende pixels, maar dat terzijde).
Waar het in 2D graphics op neerkomt is dat bij de transformatie (schaling) een doelpixel de kleur wordt gegeven van de pixel die voor de transformatie het dichts in de buurt zat. Daarbij wordt dus telkens gekeken naar 1 bronpixel en niet 4.

[MSalters]

Je zegt nu wel "8 omliggende pixels, niet 4" maar dat is niet correct.

Je bent namelijk aan het schalen. Wat je dan doet is een nieuw, kleiner ruitjesvel leggen over een bestaand ruitjesvel met grotere hokjes. Elk nieuw, klein hokje van dan in 1 van 3 categorieën: Het nieuwe hokje valt precies in het midden van een oud hok (makkelijk - zelfde kleur), het valt over de grens van 2 hokken , of het nieuwe hokje valt over een hoekpunt van 4 oude hokken.

Het zijn dus niet echt "omliggende" maar "achterliggende" pixels.

[robvanwijk]

Volgens mij gebruiken jij en koelpasta verschillende algorithmes. Om het verschil uit te leggen, elke letter is één (originele) pixel:
a a a a b b b b
a a a a b b b b
a a a a b b b b
a a a a b b b b
c c c c d d d d
c c c c d d d d
c c c c d d d d
c c c c d d d d

Wat @koelpasta voorstelt (en wat ik "nearest neighbour" zou noemen) is het volgende:
+---+---+---+---+
|a a|a a|b b|b b|
|a a|a a|b b|b b|
+---+---+---+---+
|a a|a a|b b|b b|
|a a|a a|b b|b b|
+---+---+---+---+
|c c|c c|d d|d d|
|c c|c c|d d|d d|
+---+---+---+---+
|c c|c c|d d|d d|
|c c|c c|d d|d d|
+---+---+---+---+

Terwijl jouw idee neerkomt op (wat mij betreft, "linear interpolation"):
|a a|a a|b b|b b|
-+---+---+---+-
a|a a|a b|b b|b
a|a a|a b|b b|b
-+---+---+---+-
a|a a|a b|b b|b
c|c c|c d|d d|d
-+---+---+---+-
c|c c|c d|d d|d
c|c c|c d|d d|d
-+---+---+---+-
c|c c|c d|d d|d

Waarbij de kleur van elke nieuwe pixel (elk hokje) bestaat uit de som van de vier genoemde pixels, gedeeld door vier.

Ik hoop dat dat een klein beetje leesbaar is; in tegenstelling tot GoT kan ik hier geen fixed width font gebruiken.

Normaal gesproken zou ik zeggen dat de tweede oplossing "beter" is, want het plaatje zal er minder blokkerig uitzien, maar als dat nou juist precies het doel was, dan moet je natuurlijk juist de eerste oplossing hebben.

[Reactie gewijzigd door robvanwijk op 23 juli 2024 12:22]

[MSalters]

Mooi plaatje, en dat laat inderdaad zien dat de "8 omliggende pixels" zeker fout is.

Je hebt gelijk dat met integer scaling (2:1, maar ook 3:1 etc) alle oude pixel-grenzen exact kunnen samenvallen met nieuwe, maar dat niet hoeven, In dat laatste geval heb heb je inderdaad interpolatie. Bij rationele schaling (3:2, 4:3, 5:2 etc) vallen sommige oude pixelgrenzen niet samen met nieuwe, en dus is er interpolatie - van 1,2 of 4 pixels, nooit 8.

[koelpasta]

In de praktijk bestaan die grensgevallen niet en indexeer je een integer set (de originele set pixels). De afronding naar een positie op het origineel zorgt ervoor dat je altijd maar 1 pixel indexeert.
Dat is volgens mij wat nearest neigbor doet. (het heet ook niet nearest neighbors )

In dat opzicht zijn er dus geen losstaande grensgevallen. De grensgebieden vallen door de afronding systematisch of bij de pixel ervoor of bij de pixel erna (en voor boven en onder geldt precies hetzelfde). Je kunt dus nooit tussen twee pixels uitkomen.

Over die 4 pixels vs 8 pixels ben ik het enigzins eens. Een kleinere pixel kan inderdaad door schalen nooit meer dan 4 pixels hebben die (deels) binnen zn gebied vallen. Ik dacht even te simpel en keek domweg naar alle omliggende pixels. Maar dat neemt niet weg dat de nearest neighbor methode die pixels compleet niet in beschouwing neemt en in plaats daarvan inherent een enkele pixel indexeert uit de bron. Je kunt het wel zo maken (door het bijvoorbeeld te upsamplen of een speciale significantie toe te wijzen aan alles dat eindigt op .5), maar dat is helemaal niet nodig om een nearest neighbor te berekenen.

[Reactie gewijzigd door koelpasta op 23 juli 2024 12:22]

[- peter -]

Iedere game of emulator kan toch zelf eenvoudig zo'n scaler toevoegen?

[MSalters]

Ja, maar een GPU is er écht goed in. Dit is namelijk dezelfde operatie die je moet doen als je een texture projecteert. Een GPU hoeft dus alleen één rechthoek in een scene te plaatsen, en het beeld van de oude game als enige texture op die rechthoek te projecteren. Geen bumpmapping, transparencies of andere ongein, het is zo simpel als het maar kan zijn. En voor een laptop op batterij-power scheelt het als je de hardwareacceleratie hiervoor kunt gebruiken.

[koelpasta]

Ja, maar een GPU is er écht goed in.

Niets houdt de makers tegen om de GPU te gebruiken voor hun schaling, inclusief complexere interpolatie algoritmes dan intel hier biedt

[koelpasta]

Kan iemand mij uitleggen hoe dit meer is dan de instelling dat er geen interpolatie tussen de pixels moet plaatsvinden (iets dat al in de driver zit en door de applicatie gedaan hoort te worden)?
Zover ik het zie is dit idee enorm overhyped en lost een probleem op dat eigenlijk toe te schrijven is aan brakke (game)software.

[catfish]

Veel oude games werden gemaakt door hele kleine software teams, er bestonden geen resoluties hoger dan SVGA en die code is dus relatief eenvoudig. Dat wil helemaal niet zeggen dat de code brak is.

Dit probleem is eigenlijk ontstaan door computerschermen die eigenlijk maar 1 resolutie goed kunnen afbeelden. Een oude CRT kan immers vele resoluties perfect afbeelden.
Het is eerder vreemd dat de videokaartboeren daar niet 10 jaar eerder mee zijn gekomen.

[koelpasta]

Ja, maar ja, je SVGA games draaien ook al niet echt meer native op je pc. Je videokaart snapt volgens mij helemaal niks van DOS-level VGA graphics. Daar zit een vertaallaag tussen (vaak DOSbox) die dit soort dingen hoort op te lossen. In het geval van oude DOS games is DOSBox (of equivalent) de software die ik dan brak vindt. In het geval van moderne games die tegen een moderne graphics api aanpraten leg ik de schuld bij de software zelf.

Dat het nu opgelost wordt in de laag tussen de GPU en monitor vind ik een beetje raar eerlijk gezegd. Vooral ook omdat het een instelling is die je per game moet maken en dus niet op algemeen nivo moet in gaan stellen in de driversoftware.

[Visgek82]

Huh? zeker wel. elke moderne gpu heeft nog gewoon een simpele 2d core aan boord die uitstekend zonder enige hulp met dos overweg kan. is gewoon svga compatibele

[koelpasta]

Ja, maar tegenwoordig zit er een OS tussen (tenzij je mischien puur DOS draait maar daar werkt deze driver niet op ) en mag jij vanuit die context niet vga praten tegen de GPU. Althas, zo begrijp ik het.

[iceheart]

Om het simpel uit te drukken zul je inderdaad 'via' het OS tegen de hardware aanbabbelen (en da's maar goed ook). De inhoud van wat je aan die videokaart vertelt? Dat kan, zoals Visgek82 al aangeeft, wel degelijk gewoon SVGA zijn. Dat kun je ook makkelijk zelf verifiëren: ga maar eens kijken (bij resolutie aanpassen, wel 'classic' pre-windows 8 settings gebruiken!) welke display modes je gewoon kunt gebruiken. Die worden door je GPU nog steeds gewoon ondersteund.

En maar goed ook, trouwens: veel plezier memtest86(+) te draaien als je GPU geen kaas meer van dat soort display modes zou kunnen maken, bijvoorbeeld. En zo zijn er wel meer tooltjes die we toch graag nog wel bruikbaar houden zonder een vol, modern OS te hoeven (kunnen?) booten.

[koelpasta]

Memtest is geen goed voorbeeld. Ten eerste boot je het los van windows dus heb je niks met windows graphics te maken.
En ten tweede lijkt het me sterk dat memtest een eigen VGA driver (en waarom dan geen hercules of CGA of EGA?) gebruikt voor schermoutput. Mij lijkt het logischer dat memtest daar standaard DOS calls voor gebruikt. Hoe dan ook heeft memtest niks te maken met de intel drivers uit het artiekel. Die zijn voor recente versies van windows.

Maar goed, wil je onder windows software draaien die op ouderwetse manier VGA doet (wat volgens mij niet werkt onder windows) dan heb je een soort virtuele VGA interface nodig. Meestal is dat DOSBox ofzo.

Nou, en mijn stelling was dat als je toch al een VGA scherm emuleert dat je dan ook die interpolatiezooi voor je rekening moet nemen. Het afhandelen in de driver die pas na die hele OS laag komt klinkt nog steeds raar voor mij.

[koelpasta]

Nog een verwarrend iets.
Het rechterplaatje in het voorbeeld is geen voorbeeld van pure 'nearest neighbor' interpolatie. Er vindt in het plaatje nog een andere interpolatie plaats die de randen zachter maakt.
Bij 'nearest neighbor' worden er geen 'tussenkleuren' berekend en zijn de pixels 'hard'.

[koelpasta]

Waar komt het begrip 'scaled width' in het artiekel vandaan?
Op de informatiepagina van intel komt dat begrip helemaal niet voor.

[elmuerte]

De pixel art van vroeger is gemaakt voor CRT en had geen vierkante pixels zoals we die nu zien in "retro" games.

Zie dit artikel voor een uitgebreide uitleg
https://www.gamasutra.com...in_Super_Win_the_Game.php

[MSalters]

CRT games misschien niet, maar CGA (320x240) is precies de 4x3 verhouding die monitoren vroeger hadden. En ook VGA op 640x480 had vierkante pixels.

[elmuerte]

CRT is geen video adapter standaard. Aan een CGA adapter sluit je ook een CRT beeldscherm.
Verder is CGA niet 320x240 maar 320x200, en VGA was 320x200 voor 256 kleuren. Voor 640x480 VGA had je maar 16 kleuren.
Het ding met CRT displays is dat een pixel niet perfect vierkant op het scherm te krijgen is zoals met LCD wel kan. Er is sprake van glow en bleeding waardoor pixel art er niet "crisp" uit ziet zoals op een LCD, maar veel ronder. Dit wordt ook uitgebreid besproken in de link die ik hier boven poste. Verder heeft een LCD een kaas recht grid voor de pixels, dat is bij de CRTs ook niet het geval.

Doom werd gerendered voor 320x200 met een vertical scaling van 1.2.

[djexplo]

Ze geven allemaal pixel-art achtige voorbeelden. Maar daar bij zou ik juist geen nearest-neighbor interpolation gebruiken maar "Maxim Stepin's hq2x", wiki

[ultimate-tester]

Ziet er naar uit dat hq2x het allemaal "smooth" maakt en dus niet meer pixelachtig houdt, terwijl nearest gewoon pixelachtig is, precies zoals je wilt bij dat soort dingen lijkt me.

[lordawesome]

De pixels moeten scherp blijven, ben ik helemaal met je eens. Tenzij het games waren die op een tv werden gespeeld, dan wil je ook die tv simuleren.

[MN-Power]

Dat is persoonlijke smaak. Ik vond vroeger de Amiga en C64 er op een TV mooier uit zien dan op een monitor terwijl objectief gezien het beeld slechter was. Is ook een reden waarom een emulator zo schrikken is, alles is veel kleur-echter en pixels zijn ook echt afgebakende pixels. Zelfs nu zie ik liever een zeer subtiele blur dan super gedefinieerde individuele pixels. Ik heb dan bijvoorbeeld ook totaal geen problemen met AA technieken die wat blur introduceren, en al helemaal niet als ze ook sneller zijn dan scherpere alternatieven.

[koelpasta]

Persoonlijk heb ik er een hekel aan als er pixels worden bijverzonnen. Het (nogal simpele) algoritme maakt veel fouten die de kwaliteit van de graphics juist ondermijnen.
Vroeger (eind jaren 90?) deed ik dat nog wel maar op den duur voelde het niet meer goed. Maar dan gaat het wel over klassieke 2D games die dus al van oorsprong een eigen identiteit hadden.

[Marctraider]

Mooi is dat he, een scaling methode zo oud als de weg naar kralingen, en na bijna een decade van zeuren op Nvidia forum komt men er eindelijk mee.

En vervolgens springt iedereen op de hype train, als AMD dit nog niet heeft zullen ze ongetwijfelt snel volgen.

Grote foei naar alle GPU semiconductors, en vooral naar Nvidia om het 'turing only' te maken. Omdat het zogenaamd niet anders kan.

Zo'n basis functie... in 2019. We worden met z'n allen voor de gek gehouden.

[Reactie gewijzigd door Marctraider op 23 juli 2024 12:22]

[robvanwijk]

na bijna een decade van zeuren op Nvidia forum komt men er eindelijk mee.

Ehm, nagenoeg het gehele artikel gaat over Intel (alleen de allerlaatste zin noemt nVidia snel nog even)...!?