Vulkan: een moderne api voor moderne hardware (interview met AMD)

Inhoudsopgave
  1. 1. De Vulkan-api
  2. 2. Vulkan: de ontwikkeling van een efficiëntere api
  3. 3. Vulkan 1.1, waar blijven de games?
  4. 4. Interview met AMD
  5. 5. Conclusie
  6. 6. Reacties

De Vulkan-api

Vulkan is een moderne api waarmee grafische prestaties met lage overhead mogelijk worden. Twee jaar geleden werd de eerste versie van Vulkan uitgebracht, maar waar blijven de games? Wij geven een overzicht én gaan in gesprek met AMD.

Het spreekt voor velen tot de verbeelding: software die beter en efficiënter met je hardware omgaat om zo betere prestaties, hogere framerates en lagere frametimes in games te behalen. Je kunt er nog zo'n dikke videokaart of snelle processor tegenaan gooien, soms is een spel of applicatie niet sneller te krijgen. In dat geval werkt de software niet mee, en in het geval van games kan de zogenaamde api ook een grote - en beperkende - rol spelen.

Wat is een api?

Een application programming interface (api) is een verzameling regels, definities en richtlijnen op basis waarvan software gebruik maakt van de beschikbare hardware. Deze software werkt dus tussen een programma en de hardware, en zorgt ervoor dat specifieke mogelijkheden van de hardware gebruikt kunnen worden als de software hier om vraagt. Als je in je browser een filmpje op YouTube afspeelt, wordt er een api aangesproken om de videostream (grotendeels) door de gpu te laten afhandelen en verwerken. Staat dit niet goed ingesteld, bijvoorbeeld als er geen correcte driver is geïnstalleerd, dan zal deze taak bij de cpu terechtkomen, wat in verhouding erg inefficiënt is en in sommige gevallen zelfs niet werkt.

De voor gamers bekende voorbeelden van api's zijn DirectX, OpenGL en sinds enige tijd dus Vulkan. Deze api's zorgen ervoor dat grafische berekeningen ook daadwerkelijk door de videokaart verwerkt worden. Dat klinkt logisch, maar dit is essentieel om een moderne game goed te laten draaien. Een heel groot deel van de grafische berekeningen zijn parallel van aard, waar bij de opbouw van een grafische chip rekening mee is gehouden. Videokaarten zijn uitstekend in staat om gigantische hoeveelheden relatief eenvoudige berekeningen parallel uit te voeren. Bij cpu's is dat haast het tegenovergestelde, daar is een enkele cpu-core in staat om juist snel complexe en seriële berekeningen te verwerken, al beschikken moderne processors wel over steeds meer cores.

Dominantie

De meeste games die in de afgelopen jaren voor de pc zijn uitgekomen, maken gebruik van DirectX, ontwikkeld door Microsoft. De allereerste versie kwam in 1995 uit, toen nog bekend onder de naam Windows Games SDK. In die tijd bestond OpenGL, de andere grote grafische api van toen, al drie jaar. OpenGL werd, zoals de naam al doet vermoeden, van begin af aan al met een hele andere filosofie opgebouwd. De api moest open en toegankelijk zijn voor iedereen.

In de loop der jaren is de strijd tussen DirectX en OpenGL duidelijk door Microsoft gewonnen, althans wat games betreft. OpenGL had voor professionele toepassingen wel concurrerende features, maar moest het wat betreft de doorontwikkeling van features en prestaties afleggen tegen DirectX. De dominantie van DirectX zorgde ervoor dat Windows hét platform is geworden om op de pc games te spelen, en als gevolg daarvan zijn het weer de developers die voor DirectX kiezen in het ontwikkeltraject om een zo groot mogelijke doelgroep aan te spreken. Door het gebrek aan concurrentie is Microsoft's api met elke versie maar mondjesmaat doorontwikkeld, met daarbij een hoop legacy code aan boord. Ontwikkelaars van games hebben ruim ervaring opgedaan in het programmeren voor DX, maar door restricties vanuit een oudere code base zaten er ook de nodige haken en ogen aan voor wie het onderste uit de kan van de hardware wil halen. De onvrede groeide, en er was in ieder geval één bedrijf dat vond dat het tijd was voor een schone lei..

Vulkan: de ontwikkeling van een efficiëntere api

AMD begon in 2013 met het ontwikkelen van een nieuwe api genaamd Mantle. De api werd opgebouwd om efficiënter gebruik te maken van moderne hardware, en daarbij zoveel mogelijk bottlenecks in de software weg te nemen. Dat kon omdat Mantle als low-level api werd opgezet, wat betekent dat de hardware directer aanspreekbaar is door ontwikkelaars. In ruil daarvoor moet er wel nauwkeuriger en uitgebreider worden geprogrammeerd dan in DirectX, waar juist veel zaken door de api zelf werden beheerd en afgehandeld. De ontwikkeling van Mantle heeft AMD samen gedaan met DICE (bekend van de Battlefield-games), maar de api werd alleen beschikbaar gemaakt voor de gcn-architectuur van AMD. Daarnaast werkte Mantle, net als DirectX, alleen op Windows.

Enkele games hebben ondersteuning gekregen voor Mantle, waaronder Battlefield 4, Civilization: Beyond Earth, Dragon Age: Inquisition, Mirror's Edge Catalyst, Sniper Elite III en Thief. Per game verschilde de prestatiewinst ten opzichte van DirectX behoorlijk, wat uiteraard ook weer verschilde per hardwareconfiguratie. Al met al kunnen we stellen dat Mantle vooral een geslaagd proof of concept van een low-level api was en een succesvol signaal naar game-ontwikkelaars.

Het DNA van Mantle

AMD's Mantle heeft niet genoeg grip op de markt gekregen om als zelfstandige api te kunnen voortbestaan, maar er lagen andere mogelijkheden in het verschiet. De Khronos Group, beheerder van api's zoals OpenGL, WebGL, OpenCL en gITF, was destijds bezig met het oriënteren op een opvolger van OpenGL, ook wel glNext genoemd. In dit ontwikkeltraject heeft AMD zijn Mantle-api beschikbaar gesteld als bouwstenen voor de opvolger van OpenGL, wat door de Khronos Group werd opgenomen en vanaf toen de naam Vulkan meekreeg. Vrijwel gelijktijdig werd door AMD aangekondigd dat het de publieke ontwikkeling van Mantle staakte.

Net als bij Mantle heeft Vulkan als low-level grafische api een hele rits aan voordelen ten opzichte van OpenGL en de oudere DirectX-versies. Zo is er aan de kant van de cpu onder meer een lagere overhead bij het valideren en verwerken van api-instructies, kan er een veelvoud van het aantal draw calls gegenereerd worden en heeft de ondersteuning voor multi-core processors een centrale rol gekregen. Aan de kant van de videokaart zijn er onder andere minder command buffers nodig om tot hetzelfde resultaat te komen en kan er middels asynchronous compute gelijktijdig gewerkt worden aan zowel compute als grafische taken. Bovendien is er native ondersteuning voor multi-gpu, waardoor specifieke drivers voor SLI of CrossFire niet meer nodig zijn.

De keerzijde van Vulkan ten opzichte van OpenGL en DX is het complexere programmeerwerk dat bij de ontwikkelaar komt te liggen. Er is meer vrijheid om nauwkeurig te optimaliseren, maar de veiligheid van de abstractielaag die Open GL, DirectX 11 en lager vormden, is grotendeels verdwenen. Dat betekent dat een ontwikkelaar meer kennis moet hebben van de hardware waarvoor hij of zij programmeert. Juist bij dit aspect loopt in de wereld van pc's met talloze hardwareconfiguraties sterk uiteen.

De ontwikkeling van Vulkan is met de adoptie van Mantle als basis begonnen, maar het is niet enkel AMD dat hier vervolgens aan heeft gewerkt. Onder het consortium Khronos Group vallen onder andere Arm, Intel, Nvidia, Google, Qualcomm, Nintendo, Imagination en Sony, die ook allemaal hun steentje bijdragen aan de ontwikkeling van Vulkan. Door de deelname van al deze organisaties staat een 'vendorneutrale' industriestandaard veel meer garant dan bij één of twee bedrijven het geval is. De gehele deelnemerlijst is op z'n minst indrukwekkend te noemen, met allerlei partijen uit de techsector en hardware-industrie.

Hardwareondersteuning

Ondersteuning voor Vulkan er is aan Nvidia's kant vanaf de GTX 600-serie, op AMD betreft het de gcn-architectuur (meeste kaarten uit de HD7000-serie en alle nieuwere) en bij Intel kun je met een igpu van Skylake of nieuwer aan de slag. De hardwaremogelijkheden van de betreffende gpu worden middels de Vulkan-driver doorgegeven aan de applicatie. Waar DirectX al een hele tijd met feature levels werkt, waarin een lijst met minimale vereiste mogelijkheden is opgenomen, gaat het bij Vulkan alleen om losse features met bijbehorende limieten. Geen rangorde zoals feature level 11_0 of 12_1 dus, maar een grote hoeveelheid losse specificaties. Wie hier diep in wil duiken, doet er goed aan eens te kijken op deze onofficiële Vulkan hardware database.

Vulkan 1.1, waar blijven de games?

In maart dit jaar heeft Vulkan zijn eerste grote update naar versie 1.1 gehad. Met de update zijn enkele extensies opgenomen als integraal onderdeel, is er ondersteuning om beschermde content te verwerken en kunnen met subgroup operations compute units op een gpu efficiënt met elkaar communiceren zonder de noodzaak dit via off-chip geheugen te laten lopen. Dit laatste is vooral voor compute en deep learning relevant, maar kan in potentie ook voor grafische taken nuttig zijn. Naast ondersteuning voor GLSL is nu ook support voor HLSL ingebouwd. Dit moet het porten van DX-games naar Vulkan makkelijker maken omdat shaders niet meer compleet hoeven te worden herschreven bij de overstap van api.

Ondersteunde engines, maar games?

Inmiddels is er vanuit de grotere game-engines ondersteuning ingebouwd voor Vulkan. Het betreft een hele lijst: Source 2, Unreal Engine 4, Quake Engine, id Tech versie 3 tot en met 6, Unity, CryEngine en Unigine, naast nog veel andere kleine engines. Grote games met ondersteuning voor Vulkan zijn tot nu toe enkel Doom (2016) en Wolfenstein 2: The New Colossus. Beide games draaien op dezelfde engine, id Tech 6. De prestaties in verhouding tot de grafische kwaliteit zijn in deze games uitstekend te noemen, maar omdat we hier naar een enkele engine kijken, is er binnen de Vulkan-api niet echt goed vergelijkingsmateriaal beschikbaar. Afgezien van de ondersteuning als extraatje in Dota 2, The Talos Principle en emulators zoals Dolphin en PPSSPP, komen we de veelbelovende api van de Khronos Group nog maar bij weinig spellen tegen. Waarom zien we niet meer games gebruik maken van de Vulkan-api?


Ontwikkelaars van de grotere emulators voegden al snel ondersteuning voor Vulkan toe.

Hoewel veel engines inmiddels wel ondersteuning bieden voor Vulkan, zijn veel ontwikkelaars waarschijnlijk nog niet goed thuis in het reilen en zeilen van de api. DirectX is lange tijd de enige interessante api geweest voor gameontwikkelaars en vandaag de dag is deze nog steeds dominant. Vermoedelijk hebben de meeste ontwikkelaars weldegelijk interesse in Vulkan, maar beschikken ze nog niet over de juiste hoeveelheid ervaring in het programmeren voor deze api om geheel over te stappen.

Volgens veel developers moet er in zowel Vulkan als DX12 veel meer code worden geschreven om op gang te komen dan bij de oudere api's het geval is. Het aantal assisterende tools voor Vulkan groeit, maar een moderne (pc-)game is ook met behulp daarvan niet in een paar maanden gemaakt. Als we Vulkan vergelijken met DX12 zien we ook op laatstgenoemde api niet een overvloed aan games uitkomen. Dat sluit aan bij het algehele beeld dat veel ontwikkelaars met de low-level api's nog niet de sprong in het diepe durven te wagen.

V-EZ

Een poging om de complexere werkwijze van Vulkan makkelijker te maken, is V-EZ (Vulkan Easy). Deze middleware-laag is ontwikkeld door AMD en maakt het voor ontwikkelaars makkelijker en toegankelijker om met Vulkan aan de slag te gaan. Het geheugenbeheer, een struikelblok voor veel ontwikkelaars in de low-level api's, is met V-EZ bovendien sterk versimpeld. Daarbij kan er wel gebruik gemaakt worden van de geavanceerde features van Vulkan, wanneer nodig. AMD zelf stelt dat V-EZ als transitielaag gebruikt kan worden om ervaring op te doen met Vulkan zonder een nieuwe api of framework te moeten leren. Zo wordt de low-level api weliswaar iets abstracter, maar kan dit naar wens worden aangepast.

Net als veel andere softwareprojecten is V-EZ gratis beschikbaar gemaakt op GPUOpen en GitHub.


Een schematisch overzicht van V-EZ ten opzichte van Vulkan.

Interview met AMD

Mitch Singer is de director of Software Vulkan Architecture bij AMD. Wij spraken hem over de ontwikkeling van Vulkan en stelden hem enkele vragen. Het interview kan je hieronder lezen.


Mitch Singer

HWI: Hield je voor mogelijk wat Mantle tot dusver allemaal bereikt heeft toen de ontwikkeling ervan begon? Heeft GPUOpen hier ook een rol in gespeeld?
Mitch Singer: Ja, dat was ons doel: het tonen van een betere manier om de gpu te gebruiken voor kundige ontwikkelaars, en daarmee wijdverspreide adoptie te zien. GPUOpen stelt AMD en andere partijen in staat om op een open manier in contact te komen met deze ontwikkelaars.

HWI: Wat vind je van de algehele ontvangst van Vulkan tot dusver?
Mitch Singer: We zijn blij met de opname tot op heden en kijken uit naar de verdere groei van het ecosysteem.

HWI: Hoe is het om samen met je concurrenten aan een api te werken?
Mitch Singer: AMD is toegewijd aan open standaarden om cross vendor-ondersteuning mogelijk te maken. Samenwerken met onze concurrenten zorgt voor een robuuster ecosysteem waarin softwaremakers centraler staan dan bij de visie van een enkele hardwarefabrikant het geval is.

HWI: Voor veel gebruikers voelt de adoptie van de nieuwe low-level api's aan als traag. Denk je dat de meerderheid van de gameontwikkelaars uitdagingen tegenkomen bij het implementeren van de best practices voor deze api's?
Mitch Singer: Low-level api's zijn niet voor elke ontwikkelaar geschikt aangezien ze een hoeveelheid kennis vereisen die voorheen in de grafische drivers verstopt zat. Terwijl het ecosysteem en de bijbehorende tools volwassen worden, zullen de uitdagingen waar de ontwikkelaars mee kampen, ook afnemen. De keuze van de juiste api voor een ontwikkelaar blijft zo in de handen van de ontwikkelaar zelf, precies waar het hoort. Low-level api's leveren de ontwikkelaars een infrastructuur om hun vaardigheden en kunsten in te tonen, waarbij het veiligheidsnet van de eerdere api's wegvalt.

HWI: GPUOpen maakt een hoop software en technologie open source, en AMD is hier samen met een paar anderen actiever in dan andere bedrijven in hetzelfde speelveld. Denk je dat hier een trend in zit? Zal open source de dominante richting worden voor software?
Mitch Singer: AMD blijft toegewijd aan open standaarden en de open source community, en zal volgens deze visie zijn dagelijkse activiteiten blijven uitvoeren. Of open source wel of niet de dominante speler wordt, hangt af van de uiteenlopende wensen binnen de verschillende ecosystemen.

HWI: Na de lancering van GPUOpen reageerde je concurrent snel door zelf ook een aantal technologieën open source te maken. Wat vind je van deze reactie?
Mitch Singer: Hoe meer, hoe beter!

HWI: Vulkan kan gebruik maken van extensies en vendor-specifieke extensies bestaan ook voor de api. Hoe zijn deze extensies ontvangen door de ontwikkelaars?
Mitch Singer: Zoals je verwacht hebben vendor-specifieke extensies een plek doordat ze unieke features toegankelijk maken. Echter, waar mogelijk streven we naar vendor-onafhankelijke oplossingen om het voor ontwikkelaars makkelijker te maken. We hebben bij een deel van de ontwikkelaars acceptatie gezien voor de vendor-specifieke extensies wanneer deze een significante toename in features of prestaties teweegbrengt.

HWI: AMD heeft eerder aangegeven de ontwikkeling van Mantle te beëindigen ten gunste van Vulkan. In de Radeon Settings zie ik echter verschillende versies van Mantle bij een driver van vorig jaar ten opzichte van een recentere driver. Wat is hier aan de hand?
Mitch Singer: We zetten de ondersteuning van Mantle voort voor de applicaties en hardware die er gebruik van maken. We zijn gestopt met publieke ondersteuning maar blijven het wel gebruiken voor intern gebruik. We ondersteunen de actuele low-level api's Vulkan, DirectX 12 en Metal.

HWI: Na de ondersteuning van de hardwarefabrikanten, de platformen en de game engines, is er nu het Vulkan Ecosystem Forum in het leven geroepen om een community te vormen voor het bespreken van discussies, problemen en oplossingen. Spelen de hardwarefabrikanten hier ook een rol in?
Mitch Singer: Absoluut! Het is essentiëel voor ons om vragen en problemen van ontwikkelaars te begrijpen om ze zo snel mogelijk op te kunnen lossen. Dit kan via educatie en hulp, driver updates, extra extensies en andere tools.

HWI: Een significante hoeveelheid werk is in compatibiliteit gaan zitten. Met SPIR-V 1.3 is het nu mogelijk voor ontwikkelaars om de shader language naar voorkeur te kiezen in Vulkan. Maakt de flexibiliteit van de shader language het porten van DirectX 11-spellen naar Vulkan makkelijker? Was dit een door ontwikkelaars veelgevraagde feature?
Mitch Singer: Zoals je weet specificeert Vulkan geen high level shading language en laat het deze keuze over aan de ontwikkelaar van de applicatie. Dit geeft vrijheid om zelf te kiezen en in veel gevallen maakt dit het porten tussen api's makkelijker. Dit is de sleutel in het verbinden van bestaande ecosystemen aan Vulkan en de voortzettende groei ervan, aangezien er voor ontwikkelaars altijd de keuze is uit de api die voor hem of haar het beste werkt.

HWI: De universally portable subset maakt het mogelijk om Vulkan naar DirectX 12 en Metal te mappen. En via SPIR-V ondersteunt Vulkan ook OpenCL. Is Vulkan dé api die over alle andere heerst?
Mitch Singer: Het realiseren van Vulkan op veel verschillende platformen met een scala aan features is essentieel voor het voortzettende succes van Vulkan. Het blijft echter in de handen van de ontwikkelaar hoeveel van de beschikbare features en api's er gebruikt worden op een bepaald platform.

HWI: Nauwkeurigere controle over subgroup operations, zoals enhanced compute unit control, werd mogelijk gemaakt met Vulkan 1.1. Is dit op verzoek van ontwikkelaars of is het toegevoegd voor andere high-performance compute-taken?
Mitch Singer: Hier is om gevraagd door ontwikkelaars en het is ook mogelijk bij andere api's, dus deze featureset gelijktrekken was logisch om te doen.

HWI: Waar zie je Vulkan heengaan in de toekomst? Kan een Vulkan 1.2 of 2.0 nog meer platformen en tools aan zich verbinden?
Mitch Singer: AMD is toegewijd aan Vulkan en de verbeteringen ervan die de groei bevorderen. Dat geldt voor het gehele scala aan wensen van ontwikkelaars en het mogelijk maken van de nieuwste hardwarefeatures waar mogelijk.

Conclusie

Rome is niet in één dag gebouwd, en voor moderne games en applicaties is hetzelfde van toepassing. Hoewel de specificaties van Vulkan 1.0 al ruim twee jaar geleden zijn afgerond en de api is uitgebracht, zien we vandaag de dag nog niet bijster veel software gebruikmaken van de veelbelovende low-level api. Vulkan heeft met zijn focus op flexibiliteit, schaalbaarheid en efficiëntie de potentie om de universele grafische api te worden.

De Khronos Group zorgt met de update naar Vulkan 1.1 dat ontwikkelaars minder gebruik hoeven te maken van losse extensies en meer tools ter beschikking hebben om op gang te komen met een nieuw project. Dat maakt het programmeren in Vulkan volgens velen niet direct makkelijk, maar wel overzichtelijker en toegankelijker dan voorheen. Gameontwikkelaars die eerder tegen de limieten van OpenGL en oudere DirectX-versies aanliepen, kunnen met Vulkan (en DirectX 12) volgende stappen zetten. Die nieuwe vrijheid komt met eveneens met verantwoordelijkheden, want er moet uitgebreider en diepgaander worden geprogrammeerd om die extra prestaties te oogsten. Dat zal de meest ervaren developers zeer aanspreken, maar voor wie dit niet is weggelegd, zullen de abstractere api's ook nog blijven bestaan.

0