En djupdykning i modern spelutveckling

Guld!

Här skall läsas!

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.

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?

@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.

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

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.

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

Skickades från m.sweclockers.com

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

@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.

@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).

@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.

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

@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!

@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.