En djupdykning i modern spelutveckling

Permalänk
Melding Plague

En djupdykning i modern spelutveckling

Mjukvaran och hårdvaran i dagens spelkonsoler och datorer har mycket gemensamt på pappret, men hur likartad är processen för utvecklare? Vi djupdyker i den moderna spelutvecklingen.

Läs hela artikeln här

Visa signatur

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

Permalänk
Avstängd

Spelen optimeras för 720P@30FPS med low/medium (Konsolstandard)..över dessa gränser är koderna mest ihop slängda tillsvidare, och kanske fixas till i framtiden om spelet säljer bra.

(Ta inte kommentaren för allvarligt)

Visa signatur

-Stäng av snabbstart i ditt Windows.

Permalänk
Hjälpsam

Guld!

Här skall läsas!

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Entusiast

Tack för den underbara läsningen! Var verkligen trevligt att få en bättre inblick i det här ämnet med tanke på all förvirring som de nya API'erna har skapat.

Citat:

Konceptet bakom Command Processor i Scorpio kan också vara något som grafikkortstillverkarna anammar i kommande produktlanseringar, vilket borde förbättra situationen för både befintliga och kommande DirectX 12-kompatibla speltitlar på PC-sidan.

Intressant.

Men är det inte svårt att göra en sådan? Jag kan ju tänka mig att Microsoft har lagt ner en hel del forskning om detta innan de bestämde sig för att implementera en sådan här "Command Processor", skulle Nvidia/AMD kunna göra det här själva utan någon större forskning på egen hand?
Eller är det så att det förmodligen lönar sig att implementera trots en eventuellt dyr forskning?

Visa signatur

Den digitala högborgen: [Fractal Design Meshify C] ≈ [Corsair RM850x] ≈ [GeForce RTX 3080] ≈ [AMD Ryzen 7 7800X3D ≈ [Noctua NH-U14S] ≈ [G.Skill Flare X5 32GB@6GHz/CL30] ≈ [MSI MAG B650 TOMAHAWK] ≈ [Kingston Fury Renegade 2 TB] ≈

Permalänk
Inaktiv

Bra artikel.
Jag tycker för övrigt det inte skiljer sig från så mycket annat.
När man får mer datakraft och behöver göra allt större applikationer, så faller lågnivå-optimeringar bort och det endast på ytterst få ställen.
Vanligt helt generellt när man ska göra en funktion, är att man inte direkt gör den hårdknuten till ett projekt utan gör den mer generell, vilket gör att funktionen blir mer systemkrävande, men samtidigt är mindre kostsam att underhålla då fler projekt kan dela på kostnaden.

Permalänk
Lyxfällan 🎮

@Uzanar: Tackar, kul att den uppskattades! Jo absolut, det är nog ingen självklar process med att utveckla en sådan teknik, men det är nog inte den tekniska utmaningen som håller PC-marknaden borta från liknande lösningar. Microsoft utvecklar själva mjukvaruplattformen i Xbox One och har standardiserat runt Windows 10 och DirectX 12. Eftersom deras plattform garanterat stöder DirectX 12 kan de utveckla hårdvara som specifikt riktar in sig på detta gränssnitt, vilket PC-aktörerna inte kan göra. De har ett antal olika gränssnitt att stöda (OpenGL, Vulkan, DirectX 9-12, etc) och de har grafikkort från olika generationer. Om de skulle ta fram nya grafikkort som skräddarsytts för att utföra kommandon enligt DirectX 12-modellen skulle samma spelkod sannolikt köras ineffektivt på DirectX 11-klassade grafikkort eller DX 12-kompatibla grafikkort utan en sådan Command Processor, vilket skulle utgöra en överväldigande majoritet av marknaden under några år av övergångsperiod. Så min spekulation om att det kanske är framtiden även för PC-marknaden är en spekulation som kanske blir realitet först om några år som tidigast. Men det är en spännande utveckling jag gärna skulle se, och en implementation på PC-sidan skulle ju behöva vara modellerad för att passa för lågnivå-exekvering generellt för både Vulkan- och DirectX 12-kod.

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk
Medlem

Man får en annan synvinkel utav konsoler nu efter att jag läste detta.

Visa signatur

MSI X99A GODLIKE GAMING | i7-6950X 4.3GHz | 64GB RAM 3200MHz | RTX 2080

Nintendo Switch | PlayStation 5 | Xbox Series X

Min FZ Profil

Permalänk
Medlem

Mycket bra genomgång och sammanställning - tack för den!

Visa signatur

macOS: MacBook Air 13" [M1/16/256GB], MacBook Pro 16" [M2/32/512GB], iOS: iPad Mini [128GB/LTE], iPad Pro 12,9" [M1/512GB/LTE], iPhone SE3 [128GB], Apple Watch Series 6 44mm [LTE], W10: Surface Book 3 15" [Core i7/GTX1660Ti/32/512GB], LG 77" OLED C2 [OLED77C25LB]
The purpose of morality is to teach you, not to suffer and die, but to enjoy yourself and live. --Ayn Rand
Skriv under ett upprop för en grönare energipolitik: https://energiupproret.se/

Permalänk
Inaktiv

En mycket bra artikel som förklarar det fundamentala inom programmering. Det kostar prestanda att göra det enkelt för sig. Hela idén med API:er och högnivåspråk är att göra det enklare att kunna porta koden till andra plattformar och återanvända funktioner. Det är mindre arbete att skriva kod i C jämfört med Assember. Cirkeln är sluten, från lågnivå till högnivå och åter lågnivå.

Permalänk
Medlem

Inte direkt något nytt men en bra artikel som det lagts mycket tid på och jag uppskattade den.
Vad kul att Feral Interactive var med, då jag anser att de gör det bästa portningarna till Linux just nu.

Permalänk
Medlem
Skrivet av VadSaDu:

Spelen optimeras för 720P@30FPS med low/medium (Konsolstandard)..över dessa gränser är koderna mest ihop slängda tillsvidare, och kanske fixas till i framtiden om spelet säljer bra.

(Ta inte kommentaren för allvarligt)

....portas till windows med 30fp kvarstående och någon moddare får låsa upp detta.

Permalänk
Sötast

Tack!
Mycket intressant läsning! Uppskattas.

Permalänk

Kul med Feral Interactive, som sagt.

Inte för att så många här bryr sig kanske, men är rätt övertygad om att Apples Metal får nya funktioner i MacOS 10.13 som med all sannolikhet presenteras i början av juni.

Visa signatur

• Fractal Design North | ASUS ROG Strix B650E-F | Ryzen 7 7800X3D | Radeon RX 7900 GRE | 64 GB RAM | Windows 11
• Mac Pro (Mid 2010) | 6-Core Intel Xeon ”Westmere” | Radeon RX 5700 XT | 32 GB RAM | macOS 12 Monterey | Windows 10
• MacBook Pro 14" | M2 Max | 96 GB RAM | macOS 14 Sonoma

Permalänk
Medlem

Apple å konsol fantast.
Försök att inbita läsare dif mellan pc/konsol är allt annat än spelutvecklare/konsolföretag/mjukvara(OS) fel.
Pc har fått stå tillbaka i utveckling pga dess differans å därför läggs inte tid på kodning.

Så avslutar man denna myriad av blandade åsikter om gott som blev ont, men är gott :/

Citat:

Att spelkonsolerna nu dessutom uppgraderas mitt i generationscykeln innebär dels att konsolgenerationer som begrepp börjar suddas ut, och dels att gapet mellan vilka funktioner och prestanda som erbjuds minskas mellan PC och konsoler.

Du säger tidigare i artikel att hårvara har ingen betydelse pga kodning i "programspråk" som sen kompileras med verktyg X. Där hårdvarutillverkare lämnar instruktionsuppsättningar på nya modeller kvar pga kodning. Ändå så är det nu ett problem för konsoler som programmeras "generellt" och PC sidan som har haft dessa problem LÄNGE omnämns inte?

Nyheter i all ära, men denna ger bara din åsikt som jag tolkar att du vill klaga ang spel till konsoler är för dåligt skrivna.

Visa signatur

Det du inte hinner idag hinner du inte imorgon med.

Permalänk
Medlem
Skrivet av Bloopy:

Apple å konsol fantast.
Försök att inbita läsare dif mellan pc/konsol är allt annat än spelutvecklare/konsolföretag/mjukvara(OS) fel.
Pc har fått stå tillbaka i utveckling pga dess differans å därför läggs inte tid på kodning.

Så avslutar man denna myriad av blandade åsikter om gott som blev ont, men är gott :/
Du säger tidigare i artikel att hårvara har ingen betydelse pga kodning i "programspråk" som sen kompileras med verktyg X. Där hårdvarutillverkare lämnar instruktionsuppsättningar på nya modeller kvar pga kodning. Ändå så är det nu ett problem för konsoler som programmeras "generellt" och PC sidan som har haft dessa problem LÄNGE omnämns inte?

Nyheter i all ära, men denna ger bara din åsikt som jag tolkar att du vill klaga ang spel till konsoler är för dåligt skrivna.

Oj! Det där var extremt svårtolkat och nästan obegripligt för mig.

Nu är jag iofs väldigt trött efter en lång dag (och därmed kanske lite mer "korkad"), men jag förstår i princip nada gällande vad du vill uttrycka, eller (alternativt) fråga. Sorry!

PS. Gällande artikeln om spelutveckling så tycker jag att den var både tydlig och helt logisk.

Visa signatur

macOS: MacBook Air 13" [M1/16/256GB], MacBook Pro 16" [M2/32/512GB], iOS: iPad Mini [128GB/LTE], iPad Pro 12,9" [M1/512GB/LTE], iPhone SE3 [128GB], Apple Watch Series 6 44mm [LTE], W10: Surface Book 3 15" [Core i7/GTX1660Ti/32/512GB], LG 77" OLED C2 [OLED77C25LB]
The purpose of morality is to teach you, not to suffer and die, but to enjoy yourself and live. --Ayn Rand
Skriv under ett upprop för en grönare energipolitik: https://energiupproret.se/

Permalänk
Medlem

Skulle vara intressant att ta del av listan med frågor som ej ville besvaras!

Skickades från m.sweclockers.com

Permalänk
Medlem

Lite förvånad över att hitta denna typen av artiklar på Sweclockers. Intressant!

Permalänk
Medlem

Trevlig artikel, saknade dock om aktörer som Unreal och Unity kan påverka, ex. kan dom hjälpa små utvecklare att dra nytta av asynchronous computing eller om enskilda projekt är för specifika för detta.

Permalänk
Medlem

Väldigt bra jobbat med artikeln! Insåg att jag halkat efter ett årtionde eller så i uppdateringarna. :'-)

Det enda som saknas är en slutledning. Artikeln slutar helt abrupt med något fakta om Scorpio.

Ser för övrigt tendenser till "tänker på engelska, skriver på svenska" i texten. Mest för att jag gör samma sak själv när jag försöker skriva på svenska. (Har bott utomlands de sju senaste åren.)

Permalänk
Lyxfällan 🎮

@Bloopy: Jag får nog hålla med @martinot om att jag inte är helt hundra med på vad du menar med den där formuleringen, men jag ger det ett försök. Jag skrev i artikeln att en processors instruktionsuppsättning inte spelar särskilt stor roll eftersom spelutvecklarna programmerar i ett högnivåspråk som sedan skickas in i en kompilator som gör jobbet med att anpassa koden efter hårdvaran (konvertera till maskinkod med andra ord). Vad du refererar till efter det är jag inte helt säker på, är det kommentaren från AMD om att de måste behålla instruktionsuppsättningar i nuvarande grafikkort så att det inte leder till prestandaförsämringar i framtida grafikkort om de utelämnar dessa instruktioner?

Är inte heller helt med på vad du menar om att konsoler programmeras generellt medan PC-sidan haft detta problem länge. Konsoler har programmerats hårdvarunära länge, den senaste generationen har fler lager däremellan än äldre generationers konsoler, men utvecklingen är fortfarande hårdvarunära. PC-sidan har närmat sig denna utveckling, men som sektionerna om DirectX 12/Vulkan visar är det betydligt mer komplicerat på PC-sidan på grund av den myriad av konfigurationer som finns där. Samtidigt har konsolerna börjat uppgraderats under deras livscykel, vilket för konsol- och PC-lägret närmare varandra.

Var i artikeln du hittar att jag skulle klaga på att spel till konsoler är dåligt skrivna förstår jag faktiskt inte alls.

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk
Lyxfällan 🎮

@BasseBaba: Frågeunderlaget som skickades till utvecklarna är för långt för att publiceras här i sin helhet, men sammanfattat ställde jag frågor om hur det är att programmera för Vulkan och DirectX 12, och vilka skillnader det finns i att programmera i dessa ramverk för AMD- och Nvidia-hårdvara. Det var just frågan om AMD vs Nvidia som fick utvecklarna att dra öronen åt sig, och det hjälpte inte att jag erbjöd dem att helt strunta i de frågor som ansågs vara "känsliga". När de väl hade sett underlaget tackade de nej, trots att flera av dem hade tackat ja och var väldigt entusiastiska till medverkan. Jag kan förstå att det som utvecklare eller utgivare är känsligt att ta ställning mellan två hårdvaruleverantörer, men att inte kunna bortse från dessa frågor och svara på de som inte är känsliga är mer obegripligt (och irriterande).

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk
Lyxfällan 🎮

@Fonus: Jag tar upp spelmotorernas roll som hastigast i artikeln, men intervjuerna gav upphov till så mycket information att jag omöjligt skulle kunna ta med allt. Artikeln skulle bli spretig och sakna en röd tråd. Men jag kan nämna vad AMD och Nvidia sade i frågan, och det är att majoriteten av mindre spelstudios inte har resurserna till att optimera spelen för specifika plattformar, gränssnitt eller funktioner. En liten spelstudio som väljer Unity eller Unreal Engine kan som mest optimera koden för att köras väl på plattformen, Xbox One eller PS4, medan lite större studios kan optimera för PS4 Pro, dra nytta av asynchronous compute-optimeringar, etc. Steget över det är giganter som EA DICE, Bethesdas Id Software med flera som kan utveckla egna spelmotorer, optimera för allt från asynchronous compute, Vulkan/DirectX 12 på PC-sidan, specialutvecklade lösningar för konsolerna som kramar ut varenda uns av prestanda ur hårdvaran, med mera. Studions storlek och hur mycket pengar de backas av bestämmer hur många sådana optimeringar de kan ge sin titel. Vissa spelmotorer kan ha mer moget stöd för exempelvis asynchronous compute, men det är inte så enkelt som att kryssa för det i utvecklarverktyget och bara kompilera in det i spelet, utvecklaren måste fortfarande optimera asynchronous compute efter det egna spelets förutsättningar.

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk
Lyxfällan 🎮

@Drenmi: Tack och bock! Min tanke var att Project Scorpio skulle bli en naturlig avrundning eftersom den fortfarande är det något oklara nästa steget i evolutionen av konsoler vs PC. Den kommer bli mer kraftfull, men hur kommer det påverka spelen som utvecklas för PC och Windows 10, vilken roll kommer Command Engine spela in, och kan det eventuellt spela in i utvecklingen av framtida PC-hårdvara? Men jag kan hålla med om att avslutet kan kännas något abrupt, hoppas ändå att artikeln var givande som helhet?

Hmm, jag har inte haft engelska formuleringar i huvudet när jag skrivit artikeln, men det finns ju flera områden som nämns som har engelska begrepp som ursprung. Tänkte du på något specifikt som kändes svenglifierat?

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk
Lyxfällan 🎮

@dblade: Kul att det uppskattades! Vi har publicerat andra djupgående artiklar som inte är av SweC:s typiska artikeltyper, exempelvis en annan spelutvecklar-relaterad artikel i form av Asynchronous Compute. Men även en djupgående artikel om nästa generations 5G-mobilnät, har du inte läst dessa finns det lite ytterligare läsning där

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk
Medlem

Mycket spännande artikel @loevet. En lång uppföljning på det @Yoshman pratat om tidigare i diverse trådar.

Visa signatur

Dator: Lian Li O11 Dynamic, R9 5900X, MSI X570 ACE, Corsair H150i Pro, G.Skill TridentZ@3733MhzCL16, ASUS RTX 3090 TUF OC, Firecuda 530 2TB, 990 Pro 2TB, Corsair RM850x.
Skärm: LG OLED 42C2

Permalänk
Medlem
Skrivet av loevet:

@BasseBaba: Frågeunderlaget som skickades till utvecklarna är för långt för att publiceras här i sin helhet, men sammanfattat ställde jag frågor om hur det är att programmera för Vulkan och DirectX 12, och vilka skillnader det finns i att programmera i dessa ramverk för AMD- och Nvidia-hårdvara. Det var just frågan om AMD vs Nvidia som fick utvecklarna att dra öronen åt sig, och det hjälpte inte att jag erbjöd dem att helt strunta i de frågor som ansågs vara "känsliga". När de väl hade sett underlaget tackade de nej, trots att flera av dem hade tackat ja och var väldigt entusiastiska till medverkan. Jag kan förstå att det som utvecklare eller utgivare är känsligt att ta ställning mellan två hårdvaruleverantörer, men att inte kunna bortse från dessa frågor och svara på de som inte är känsliga är mer obegripligt (och irriterande).

Vad jag kan förstå så har en del smutskastning skett på senare tid mellan olika spelutvecklare när de dragit upp OpenGL, Vulkan och drivrutiner mellan olika tillverkare (AMD, Nvidia, Intel) på olika plattformar.

Tror det var runt 2016 som ett antal utvecklare började skriva på sin blogg om vad de anser är rätt/fel och sedan började en del pajkastning på twitter och forum. Vem vet vilka konsekvenser det blev efter affären både mellan utvecklarna och hårdvarutillverkaren och själva cheferna där.

Tror mycket väl att detta är grunden till att de drog ur sig så fort AMD/Nvidia nämndes, inte tal om all kritik och kontroverser kring dx 10.1, Nvidia meant to be played mm.

Visa signatur

Arch - Makepkg, not war -||- Gigabyte X570 Aorus Master -||- GSkill 64GiB DDR4 14-14-15-35-1T 3600Mhz -||- AMD 5900x-||- Gigabyte RX6900XT -||- 2x Adata XPG sx8200 Pro 1TB -||- EVGA G2 750W -||- Corsair 570x -||- O2+ODAC-||- Sennheiser HD-650 -|| Boycott EA,2K,Activision,Ubisoft,WB,EGS
Arch Linux, one hell of a distribution.

Permalänk
Medlem
Permalänk
Datavetare

@loevet: riktigt spännande läsning, tackar!

En personlig kommentar angående Metal vs övriga APIer. Är ju rätt flytande vad man menar med "lågnivå" när man pratar om saker som API för att jobba mot GPU, i traditionell bemärkelse är ändå alla dessa APIer (inklusive DX12/Vulkan), högnivå APIer då de presterar en rätt abstrakt modell av en GPU. Precis som artikel nämner vid flertalet tillfällen skrivs ju både shaders och koden som jobbar mot APIerna i ett högnivåspråk (som i alla lägen är någon variant av C eller C++), detta kompileras sedan till underliggande maskinvaruinstruktioner.

Det som är är lika för Metal, DX12 och Vulkan är att alla dessa har en grundabstraktion där en GPU är en I/O-enhet som kan ta jobb som faller inom en av tre huvudklasser: grafik ("vanlig 3D grafik"), beräkning ("GPGPU") samt minnesoperationer (skyffla data). Med väldigt stora penseldrag har man i alla tre APIerna en eller flera kommando-köer där man postar jobb som faller inom en av tre huvudklasserna. Att paketera data och bestämma när allt skickas till GPU är helt explicit (just detta var väldigt implicit tidigare, en del i att "speloptimera" drivers var just att lägga in heuristik som avgör hur länge drivern ska vänta innan den skickar saker till GPU).

Tidigare DX-versioner samt OpenGL var i grunden en stor tillståndsmaskin (ajabaja att använda den från flera trådar) och enda egentliga hårda barriären för att skicka något till GPU var när en scen färdigställs och nästa påbörjades.

Skulle ändå säga att det inte gör Metal, DX12 och Vulkan med lågnivå. Skulle säga att de har en abstraktion som ligger långt närmare hur en modern GPU ser ut idag, något som kraftigt minskar mängden kod som behövs i driver. Är mer denna bättre abstraktion som möjliggör att mycket validering kan ske endera up-front (vid kompilering) eller vid ett enda tillfälle (där saker laddas) jämfört med tidigare DX och OpenGL där validering gjordes vid varje förändring av tillståndsmaskinen.

I DX12 och Vulkan däremot mycket av resurshantering explicit på ett helt annat sätt än Metal. Saker som manuell minneshantering och liknande kan med stort fog kallas "lågnivå". Har lite svårt att se värdet manuell hantering av t.ex. minne. På en konsol, absolut då det är en väldefinierad plattform. Men hur kan detta vara en bra idé på PC? Hur man optimalt lägger ut saker i VRAM beror ju på en rad faktorer, t.ex. hur bred bussen är och hur minnesrymden är fördelade över minneskanaler. Verkar faktiskt rent korkat att lägga dessa detaljer i knät på utvecklarna när det inte bara skiljer sig mellan AMD och Nvidia utan även mellan kort i olika segment.

I Metal är resurshanteringen betydligt mer lik gamla DX och OpenGL, så skulle kalla Metal för en modern variant av de gamla högnivå APIerna. Tror också att Apple är de som träffat bäst i balansen mellan hur mycket saker ska vara explicita (för att möjliggöra maximal prestanda) och hur mycket som är automatiskt (för att göra det enkelt att använda).

Nog svamlat från min sida, mer sådana här artiklar!

Visa signatur

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

Permalänk
Lyxfällan 🎮

@Yoshman: Tackar, kul att den uppskattades! Jo absolut, jämfört med sann lågnivåprogrammering är vare sig PC eller moderna konsoler äkta lågnivå, på den tiden när spelen bestod av maskinkod som skrevs in på kassetternas lagringsminne och kördes direkt mot konsolens hårdvara var det äkta lågnivåprogrammering. Det vi har idag handlar snarare om "snabbare åtkomst till hårdvaran än OpenGL/DirectX 11-generationen". De stora utvecklarna som tar sig an DX12 och Vulkan idag måste ändå göra koden ganska generell för att den ska kunna köras på en mängd olika konfigurationer, och återuppfinner i princip hjulet på vissa punkter jämfört med vad drivrutinsmakarna gjort under flera år, men det kan ju också ge resultat om de kan lägga tillräckligt mycket resurser på det. DOOM är ju ett utmärkt exempel på det, Battlefield 1 i mindre utsträckning.

Ja det är något jag fått intrycket från de jag har pratat med inför den här artikeln, att Metal egentligen är den gyllene mellanvägen mellan de klassiska högnivåramverken och DX12/Vulkan. Apple gör överlag ett mycket bra jobb med utvecklarverktyg. De tog ju fram OpenCL ursprungligen, Metal är ett utmärkt utvecklargränssnitt, Swift är ett modern och mycket uppskattat språk, de tog in och började använda LLVM-verktygen i sin utveckling, med mera. Metal-modellen hade säkerligen lett till att fler små utvecklare skulle kunna utnyttja fördelarna med lågnivå-liknande gränssnitt.

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk
Medlem

Finns ganska mycket abstraktion i OpenCL och Vulkan som jag uppfattat det – båda använder ju numera mellanformatet SPIR-V. Det är också varför gränssnitten slås ihop under Khronos. Just övergången från tidigare SPIR (1.2, 2.0) till SPIR-V (OCL 2.1, Vulkan) betyder ju också att det inte längre är baserat på LLVM IR, och kan göra saker LLVM inte stödjer även om LLVM fortfarande används ihop med det. Sen är det ju drivrutinerna som kompilerar SPIR-V till maskinkod. Den typ av abstraktion är nog riktigt bra, och de arbetar t.o.m. på att få in GLSL där vilket skulle betyda att du kan fortsätta använda GLSL men kompilera det till SPIR-V istället som tidigare i OpenGL där GLSL hade sin egna kompilator i drivrutinen. Flyttar runt lite vart arbetet görs, kan samtidigt förenkla.

Gemensamt för alla nya APIer verkar vara just att förenkla utvecklingen av drivrutinerna. DX och Metal kanske inte är lika flexibla på front-endsidan med verktygen dock, hur som helst behövs de nog mogna lite till för alla de nya APIerna. Motorerna måste få bättre stöd också, motorerna abstraherar ju i sin tur väldigt mycket för spelmakarna, där många har egna shaderspråk och dylikt, men det kan ju också hjälpa spel/motorer att porteras till andra plattformar som konsolerna utan att de som sitter och utvecklar innehållet behöver sitta och konvertera shaderformat eller dylikt.