Spillere med Intel-grafik på Linux kan få en mere direkte vej til grafikkortets specialiserede beregninger. Et sæt offentlige kodeforslag skal gøre det muligt for XeSS at bruge XMX gennem Proton i stedet for den langsommere reservevej, som udvikleren beskriver.

Ved Elektronikas gennemgang tirsdag den 20. oktober står forslagene stadig åbne. De blev indsendt den 19. oktober. Det er derfor en aktuel udviklingshistorie, ikke en meddelelse om, at alle Steam-brugere har fået funktionen i dag.

Det samlende forslag i Valves Proton-projekt er indsendt af Damian Tomczak under kontoen damian-tomczak-intel. Det knytter ændringer i Proton sammen med arbejde i Wine, vkd3d-proton og DXVK.

For den almindelige spiller er pointen enkel: Det er ikke nok, at en chip fysisk indeholder en funktion. Hele softwarevejen fra spillet til hardwaren skal kunne bruge den.

Hvad XeSS gør

Intel beskriver i sit officielle XeSS-projekt flere teknologier under samme navn. Super Resolution arbejder med billedrekonstruktion, mens Frame Generation handler om at skabe ekstra billeder. Xe Low Latency skal reducere forsinkelse.

Det er forskellige opgaver. En forbedring af vejen til opskalering er derfor ikke automatisk et løfte om, at alle funktioner i den samlede pakke bliver tilgængelige eller forbedret samtidig.

Ved opskalering er grundideen at danne et billede til en højere udgangsopløsning på baggrund af en mindre krævende gengivelse. Det kan give mere råderum til grafikkortet, men det endelige resultat afhænger af både spillet og den konkrete implementering.

XMX er Intels særlige matrixberegningsenheder. De er relevante for den Intel-optimerede vej, som dette arbejde forsøger at gøre tilgængelig gennem kompatibilitetslaget. Nyheden handler dermed om at forbinde eksisterende dele bedre, ikke om en ny fysisk grafikchip.

Proton er mellemleddet

Valve beskriver Proton som et kompatibilitetsværktøj baseret på Wine og yderligere komponenter. Det gør det muligt at køre Windows-spil gennem Steam på Linux.

Det er en vigtig skelnen: Et spil bliver ikke nødvendigvis omskrevet til Linux, bare fordi det kan køre der. Et lag af software hjælper i stedet med at få spillets forventninger til systemet til at passe med den platform, det faktisk kører på.

Når et spil bruger leverandørspecifik grafikfunktionalitet, kan der derfor være mere at forbinde end almindelig gengivelse. Spillet skal kunne finde den rigtige funktion, og de objekter og data, som sendes videre, skal kunne forstås i den anden ende.

Det forklarer, hvorfor en tilsyneladende lille funktion kan kræve ændringer flere steder. En opdatering i ét projekt løser ikke nødvendigvis de antagelser, et andet projekt stadig arbejder ud fra.

En bro til Linux-biblioteket

Forslaget til Wine tilføjer et indbygget bibliotek, der videresender XeSS-kald fra Direct3D 12 til Linux-udgaven af XeSS. I udviklerens beskrivelse håndteres forbindelsen til Vulkan gennem vkd3d-protons grænseflade.

I praksis er idéen, at spillet fortsat møder en forventet Windows-grænseflade, mens arbejdet kan sendes videre til et bibliotek, der passer til Linux. Det er en oversættelse mellem softwaredele, ikke en ændring af selve spillets historie, grafikfiler eller indhold.

Udviklerens beskrivelse siger, at spillets eget bibliotek fortsat bruges, hvis den nødvendige Linux-del ikke findes. Dermed er forslaget ikke udformet som et ubetinget skift for enhver installation.

Den type reservevej er væsentlig, fordi brugernes computere ikke er ens. Drivere, biblioteker og spilversioner kan variere. En ny mulighed må helst ikke gøre en tidligere fungerende kombination ubrugelig, blot fordi én komponent mangler.

Flere dele skal passe sammen

Det tilknyttede forslag til vkd3d-proton handler om at aktivere de Vulkan-udvidelser og funktioner, som XeSS kræver. Den del illustrerer, at et bibliotek ikke kan stå alene: De underliggende muligheder skal også være eksponeret.

I DXVK-forslaget ændres håndteringen af en eksisterende omgåelse, som skjuler Intel-grafik for bestemte XeSS-kombinationer. Når XeSS leveres gennem den nye Proton-vej, skal den omgåelse ikke automatisk spænde ben.

Diskussionen i DXVK indeholder samtidig konkrete indvendinger fra projektets vedligeholder om, hvornår kontrollen udføres, og hvordan den påvirker spillets forventninger. Det er en synlig del af kodegennemgangen, ikke et tegn på, at ændringen allerede er godkendt.

For læseren er det et nyttigt indblik i, hvad en offentlig udviklingsproces faktisk viser. Man kan se både intentionen og uafklarede detaljer. Et åbent forslag er mere konkret end et rygte, men mindre end en færdig funktion.

Ingen procentgevinst endnu

Elektronika har ikke målt ydelsen af ændringerne. Artiklen giver derfor ingen procenttal for højere billedhastighed og lover ikke en bestemt forbedring i et navngivet spil.

En meningsfuld test bør sammenligne den samme maskine, den samme scene og de samme indstillinger. Ellers kan forskelle i billedhastighed skyldes andet end den nye softwarevej.

Billedkvaliteten bør også vurderes under bevægelse. Et skarpt stillbillede fortæller ikke nødvendigvis, hvordan fine detaljer, gennemsigtige objekter eller hurtigt bevægende elementer ser ud i spil. Det er muligt at få et højere tal i hjørnet af skærmen uden, at hele oplevelsen bliver bedre.

Endelig er stabilitet afgørende. En løsning, der virker i én kort test, er ikke nødvendigvis klar til mange timers spil på tværs af titler. Det er blandt grundene til, at offentlige kodeforslag skal gennemgås og afprøves, før de bliver en almindelig del af en udgivelse.

En grundig sammenligning bør desuden notere, hvilken XeSS-tilstand der faktisk er aktiv. To skærmbilleder med den samme menuindstilling er ikke nok, hvis de underliggende softwaredele vælger forskellige veje. Versionsnumre og testbetingelser er derfor ikke ligegyldige detaljer, men nødvendige for at andre kan efterprøve resultatet. Det gælder især her, hvor hele formålet er at ændre forbindelsen mellem et Windows-spil og et Linux-bibliotek. Uden den dokumentation kan en lovende måling være svær at skelne fra en forskel i opsætningen.

Hvad man kan holde øje med

Det næste klare skridt vil være, om ændringerne bliver accepteret, og hvordan de derefter indgår i en udgivet Proton-version. Derefter skal dokumentationen gøre det tydeligt, hvilke drivere og biblioteker der kræves.

Indtil da bør en almindelig bruger ikke læse nyheden som en besked om at udskifte systemfiler eller installere tilfældige pakker. Udviklingskode og en understøttet opdatering er ikke det samme.

Elektronikas vurdering er, at arbejdet er interessant, fordi det angriber en konkret forbindelse mellem software og hardware. Hvis det bliver færdigt og fungerer stabilt, kan det gøre eksisterende Intel-grafik mere nyttig til Windows-spil på Linux. Hvor stor forskellen bliver, må dokumenteres med den endelige implementering.