Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 86 reacties

Ontwikkelaar Axel Gneiting heeft Quake 1 geport naar de Vulkan-api. Hij deed dit in zijn vrije tijd naast zijn werk als programmeur voor id Software voor het porten van de 2016-versie van Doom naar Vulkan.

VkQuake maakt gebruik van het bekende opensource-Quake-project QuakeSpasm. De code van vkQuake is te vinden op GitHub. Gneiting toont een beeld van zijn Vulkan Quake 1-port die 'In the Shadows' draait op Twitter. Er mist nog wel het een en ander in de code, schrijft hij.

quake 1 vulkan

Vulkan is een low level api voor het aansturen van de gpu. De api is grotendeels van AMD's Mantle afgeleid. en geeft direct toegang tot diepere lagen van grafische hardware wat voor lagere overhead zorgt. Vulkan wordt ontwikkeld door de Khronos Group dat ook onder andere OpenGL onder zijn beheer heeft. Het wordt ondersteund door veel platforms, op dit moment Windows, Linux en Android. Apple heeft sinds 2014 zijn eigen Metal-api en lijkt Vulkan niet meer te willen ondersteunen in iOS en OS X.

Moderatie-faq Wijzig weergave

Reacties (86)

Ik denk dat Vulkan in de nabije toekomst erg groot gaat worden icm Android en later SteamOS. Apple blijft koppig Metal promoten (dat overigens wel heerlijke prestatie verbeteringen brengt in el Capitan) maar op de lange duur wordt Vulkan na DirectX de industrie standaard.

Als Apple betere spelondersteuning wil op vooral macos lijkt het me verstandig dat ze in de toekomst ook Vulkan gaan ondersteunen naast Metal. Zoniet dan zullen macs achterblijven op steamos ports van grote games. Tot nu toe hebben macs mee geprofiteerd van Valve's steamOS initiatief, mede omdat macs voorheen openGL als standaard API gebruikten. Als Apple nu aan metal blijven vasthouden valt die synergie met Valve weg en wordt de stroom van ports voor MacOS wellicht onderbroken.

[Reactie gewijzigd door parryfiend op 25 juli 2016 21:23]

Vooral werd ik weggeblazen door benchmarks waar vulkan en directx vergeleken worden op amd en Nvidia kaarten. Op amd gewoon echt tot 40% meer fps met vulkan vs dx.
Toch jammer dat dit niet bij Nvidia ook het geval is maar dit zou kunnen duiden dat Nvidia drivers al voor minder overhead zorgen en dat amd drivers misschien gewoon erg slecht gecodeerd zijn.
Vulkan is afgeleid van amd's mantle api. Is niet zo vreemd dat vooal amd gpu's een flinke performance boost krijgen onder vulkan drivers.
Mits de programmeur zijn werk goed doet, want dat is bij low-level API's erg belangrijk, heeft Vulkan erg veel baat bij meer cores, iets waar de chips van AMD beter in voorzien dan die van NVidia. Dat komt inderdaad zeer waarschijnlijk omdat het is afgeleid van Mantle, AMD heeft uiteraard de API gemodelleerd naar hun hardware.

Dat de drivers van AMD van minder goede kwaliteit zijn dan die van NVidia, of dat in ieder geval waren, zal ook zeker een factor zijn want met een low-level API gebeurd er minder in de driver en meer aan de kant van de game of andere software. Als de dat roept krijg je echter al snel de AMD fanboys over je heen.

edit: Wat betreft Apple, ik geloof dat er wel gewerkt wordt aan een "Vulkan on Metal" implementatie, maar dat zorgt natuurlijk weer voor extra overhead.

[Reactie gewijzigd door rbr320 op 25 juli 2016 23:49]

Ondanks dat ze feitelijk hetzelfde doen ('videokaarten') zijn de eigenlijke kaarten (de hardware dus) heel verschillend, waardoor AMD (als ik het goed heb) beter is met het renderen van omgevingen, en NVIDIA beter is met effecten, ieder maakt dan ook bewust drivers & software die vooral op hun ding werken.

Zie bijvoorbeeld de recente (zwaar overtrokken) huilbui van AMD over NVIDIA GameWorks, het hele punt erachter (wat AMD voor het gemak weg liet) is dat NVIDIA hardware nou eenmaal beter is in de dingen die in GameWorks zitten (effecten en physics) dus daarom dat het zoveel beter werkt op NVIDIA hardware.

Vergelijkbaar verhaal met Mantle Vulkan, het is grotendeels door AMD gemaakt, met in het achterhoofd de hardware designs van AMD, dus dan werkt het verreweg get beste op AMD hardware. (Alleen gaan ze bij NVIDIA niet huilen tegen alle grote Amerikaanse game sites, dus vandaar dat je bijna niets negatiefs over Vulkan hoort, NVIDIA pakt het anders aan (zie recente vid kaarten))

Het klopt trouwens dat de drivers van NVIDIA (op windows iig) wat 'lichter' zijn dan die van AMD, wat verder niet zoveel zegt, behalve dat NVIDIA drivers wat 'lichter' zijn dan die van AMD, heeft verder weinig te maken met de prestaties van de videokaarten in allerhande games.

[Reactie gewijzigd door olivierh op 27 juli 2016 17:42]

Van wat ik zie onder developers word Vulkan weer een nieuwe OpenGL. DirectX12 heeft betere tools. Voor die 0,5% Linux gebruikers ga je niet een slechtere API gebruiken. De teams die hun eigen engine onderhouden brengen toch zelden iets uit op Android of Linux.

De vraag is alleen hoe relevant het nog is. 90% van de developers gebruikt toch Unity of Unreal. Dan gebruik je automatisch DirectX op Windows, Metal op MacOS en Vulkan op Linux.

[Reactie gewijzigd door Wolfos op 26 juli 2016 10:56]

Als slechts één ontwikkelaar een game naar Vulkan kan porten waarom zijn er dan op dit moment zo weinig Vulkan games aangekondigd |:(

Benchmarks bewijzen dat Vulkan voor 20-30% verbetering kan zorgen. En mijn eigen ervaring met Doom is dat het screen tearing ook oplost. (vsync uitgeschakeld)

[Reactie gewijzigd door et36s op 25 juli 2016 20:35]

De reden waarom spellen vooralsnog even op zich laten wachten is dat Vulkan van wege zijn low-level-aanpak een API is die relatief veel arbeid vergt om goed gebruikt te worden. Een bestaande spelengine omzetten naar Vulkan is al arbeidsintensief, omdat je allerlei code moet toevoegen die normaal OpenGL voor je oplost. Als je dat doet ga je delen van die code in de prestatiekritieke paden uitvoeren, terwijl voor goede Vulkan-prestaties dat soort code buiten de kritieke paden gehouden moet worden. Omdat goed te doen, moet dan de engine flink herschreven worden.

Het ontwikkelen van een spelengine duurt 2-3 jaar. Daarna moet het spel nog ontwikkeld worden, wederom 2-3 jaar. Vulkan-ondersteuning voeg je niet even in het laatste stadium van ontwikkeling toe. En daarom moeten we nog eventjes geduld hebben voor er echt veel Vulkan-spellen gaan komen.
Het ontwikkelen van een spelengine duurt 2-3 jaar. Daarna moet het spel nog ontwikkeld worden, wederom 2-3 jaar. Vulkan-ondersteuning voeg je niet even in het laatste stadium van ontwikkeling toe.
Sorry maar dit is echt nonsens :). Sowieso maakt vrijwel niemand een render engine from scratch, er wordt altijd wel uitgegaan van een bestaande codebase waar op voortborduurd wordt, wat betekent dat een game in tandem met een nieuwe generatie engine ontwikkeld kan worden.

Daarnaast is het, met een goede opzet, prima mogelijk om een andere rendering backend achteraf te implementeren, en daar is echt geen heel team voor nodig die daar 2 a 3 jaar over doet.
Ergens heb je natuurlijk gelijk, alleen is de nieuwe generatie grote game engines in de afgelopen jaren al ontwikkeld, nog voordat de Vulkan specificatie 100% compleet was. Die specificatie is namelijk pas afgelopen februari officieel gepubliceerd en de Vulkan renderer moet dus in vrijwel alle gevallen achteraf worden toegevoegd. Natuurlijk hadden de leden van de Khronos groep toegang tot de vroegere, onvolledige specs en konden zij alvast aan de slag. Daarom heeft Dota 2 dat op Valve's Source 2 engine draait nu al ondersteuning voor Vulkan. In andere grote engines zoals Unreal Engine 4 en Unity3D is de ondersteuning voor Vulkan echter nog niet compleet en dus nog niet beschikbaar voor spelontwikkelaars. id Software was er met idTech 6 waar de nieuwe Doom op draait eigenlijk verrassend snel bij wat mij betreft.

Andere spellen en engines waarvan ik weet dat er een Vulkan backend voor komt zijn Ashes of the Singularity dat op een eigen engine draait, de Serious Engine 4 van Croteam, waar ze een nieuwe Serious Sam op willen bouwen, en de Road Hog engine waar de nieuwe Shadow Warrior op wordt gebouwd. In welke mate deze engines echter voor andere spellenmakers in licentie te nemen zijn weet ik niet.
Ik raad je aan eens de discussis in de Vulkan-draadjes te te lezen op het Steam forum van The Talos Principle. De programmeurs geven daar behoorlijk wat informatie over de uitdagingen die ze tegenkomen. Het implementeren van Vulkan in een back-end is wel mogelijk en hebben ze ook op die manier gedaan, alleen:
  • Kost dat meer werk dan bijv. een OpenGL-backend.
  • Lukt het niet goed om op die manier de voordelen van Vulkan te benutten.
Om de voordelen van Vulkan te benutten, moet de hele engine op de schop.

Dit is precies de reden dat Doom zoveel voordeel uit Vulkan haalt, terwijl Vulkan bij The Talos Principle vooralsnog tussen OpenGL en DirectX11 in zit kwa prestaties.
Dat ligt dus aan de opzet van de engine. Door die zo high level mogelijk te abstraheren, beschik je over heel veel informatie over wat er gedaan moet worden.

Nou hebben wij nog niet met het Vulkan bijltje gehakt, maar onze engine heeft behoorlijk wat verschillende backends gezien: DX9, DX11, DX12, Xbox 360 (vergelijkbaar met DX9 maar met iets lower level calls), PS3, PS4 en tot slot Mantle. Volgens mij heeft geen van die implementaties meer dan 2 manjaren gekost. Maar ja, je wordt er dan ook op een gegeven moment handig in ;)
Zou het dan ook mogelijk zijn om high-level calls te compileren naar low-level calls? Ik weet echt te weinig van programmeren in OpenGL en DirectX af om hier zelf iets nuttigs over te zeggen, maar het lijkt mij dat hier potentieel meer winst met minder tijd te behalen valt dan alles herimplementeren in Vulkan.
Dat is feitelijk precies wat een API doet. Alleen kan een generieke API zoals DirectX en OpenGL niet high level genoeg zijn want dat limiteert wat je met de API kan. Maar ze kunnen ook weer niet low-level genoeg zijn want dat limiteert de hardware die door de API aangestuurd kan worden.

En dat is dan ook het "probleem" van Vulkan en DirectX 12. Oudere hardware zal er nooit door ondersteund kunnen worden omdat ze niet werken volgens het model dat door die API's aan de gebruiker wordt aangeboden.

Maar vergis je niet: de hoeveelheid optimalisaties die de drivers toepassen in API's als OpenGL en DirectX 11 zijn enorm. Diezelfde optimalisaties kunnen ze niet meer toepassen in Vulkan en DirectX 12 door hun low-level karakter, en dus is het aan de gamedevelopers om de maximale performance eruit te halen. In principe kan een game de boel beter optimaliseren dan een driver omdat het meer informatie heeft over zijn eigen gebruikspatronen, maar het is wel iets waar wat expertise voor nodig is. Het is niet dat door gewoon maar gebruik te maken van de nieuwere API's dat alles dan ineens zomaar sneller is. Over het algemeen zie je in een eerste implemenentatie juist een verlies in performance, omdat alles nog niet gestroomlijnd is.

[Reactie gewijzigd door .oisyn op 26 juli 2016 11:37]

Als je een Mantle renderer hebt zou het inderdaad weinig moeite moeten kosten om tot een fatsoenlijke Vulkan renderer te komen toch? Aangezien Mantle de fundering is van de Vulkan API.
Hoe rijm je die 2 manjaar met het feit dat deze Quake engine door 1 persoon in zijn vrije tijd gedaan is? Is die engine zo veel makkelijker dan de huidige engines?
Volgens mij geef je zelf het antwoord al. Quake 1 engine is vrij simoel vergeleken met huidige engines.
Of we onderschatten een beetje wat competente en gedreven mensen kunnen bereiken in korte tijd: https://github.com/jeaye/q3.
Als EA het in een nieuwe versie van de frostbite engine kan krijgen dan hebben we naast de Unreal engine toch wel een groot aantal Games te pakken.
Waarom zou Vulkan screen tearing op moeten lossen? Screen tearing gebeurd door verschillen in FPS vs refresh rate van de monitor, dus ondersteunen ze dan iets als Freesync?

20-30% verbetering ten opzichte van wat trouwens? DX12? Zo ja: impressive. Zo niet: hoe verhoud het zich en waarom moeten we dan Vulkan hebben ipv DX12?
Dx12 is weer ms only dus daar heb je niet veel aan gezien het feit dat de meeste computers unix/linux draaien. Dat zal de markt wel zijn waar ze heen willen - telefoons, tablets, settop boxes, tv's etc etc.
DX12 is niet alleen MS-only, maar ook nog eens Windows 10 only. Dus alle gamers die om wat voor reden dan ook weigeren over te stappen van Windows 7 of 8.1 naar Windows 10, maar die wel redelijk nieuwe en dus Vulkan compatible (en dus in principe ook DX12 compatible) hardware hebben kan je met deze API toch voorzien van de beste grafische prestaties van je nieuwe game.

edit: om de vraag van @Michaelr1 direct te beantwoorden, de presaties van Vulkan en DX12 blijken in de praktijk zeer vergelijkbaar, net zoals de API. Het programmeren van een renderer met 1 van beide API's vertoont volgens een developer van Ashes of the Singularity zelfs zoveel overeenkomsten dat je volgens hem net zo goed meteen beiden kan doen.

[Reactie gewijzigd door rbr320 op 26 juli 2016 00:13]

Da's leuk bedacht, maar Vulkan vereist wel een bepaalde generatie van hardware-architectuur. De kans dat je het binnenkort op embedded/mobile devices gaat zien is relatief klein.

.edit: Ik lees dat er ook een Android implementatie is. I stand corrected :). Ben wel benieuwd welke SoC's ondersteund worden.

[Reactie gewijzigd door .oisyn op 25 juli 2016 22:24]

Vooralsnog heeft alleen Samsung apparaten uitgebracht met Vulkan-ondersteuning.
Nvidia met hun shields ook
Google's Android N komt met geintegreerde Vulkan support. Wordt flinke upgrade tov opengl es.
Als je telefoon OpenGL ES 3 ondersteund dan ondersteund die Vulkan ook.
Daar heb ik geen antwoord op maar heb Doom laatst gekocht. Zowel de game met openGL als Vulkan geprobeerd.

Bij Vulkan heb ik geen screen tearing. Bij OpenGL is het extreem tenzij ik Vsync inschakel met gevolg een fps die instort. Op een Nvidia GTX960. Heb geen Freesync/Gsync monitor dus waar het aan ligt? I don't know.
Het kan een verschil tussen double en tripple buffering zijn. Bij double buffering heb je zoals de naam doet vermoeden maar 2 buffers: front en back. De front buffer is waar je display device de pixels uitleest om naar je monitor te sturen, de back buffer is waar de GPU naar rendert. Op het moment dat een frame klaar is, kan hij switchen tussen front en back. Zonder vsync resulteert dat natuurlijk in tearing, omdat hij halverwege het scherm ineens een andere buffer laat zien. Met vsync moet hij op dat moment wachten totdat alle pixels uit de front buffer zijn uitgelezen. Het resultaat daarvan is dat je framerate altijd een deler van de framerate van je monitor gaat zijn. Bij een 60Hz monitor kun je dus bijv. slechts op 60/1 = 60 fps, 60/2 = 30 fps, 60/3 = 20 fps, etc runnen. Als je de 60 dus nét niet haalt, dan keldert de framerate naar 30 fps, omdat hij een hele tijd moet wachten totdat hij weer het beeld ververst.

Bij tripple buffering heb je een extra buffer. Als de back buffer klaar is wisselt hij de back buffer met de temporary buffer, en kan de GPU meteen door met de volgende frame. Bij de vsync wisselt hij vervolgens van front buffer en temporary buffer. Resultaat: geen tearing en variabele framerates die geen deler hoeven te zijn van de refresh rate van je monitor.

[Reactie gewijzigd door .oisyn op 26 juli 2016 14:08]

blijft gek maar ik denk dat hij doelt op het verbeteren van prestaties (20-30%) waardoor hij met zijn setup minder screen tearing ervaart. Hij zal wel dichter met z'n FPS in de buurt zijn gekomen van z'n monitor refresh rate, zou ik denken.
het blijft een wazige statement om te maken zoals je aangeeft.
Omdat Quake 1 heel erg klein is. Je hebt maar 80 MB nodig en 24 MB ram. De moderne spellen zijn 100 keer groter.

[Reactie gewijzigd door NiLSPACE op 25 juli 2016 21:00]

Als slechts één ontwikkelaar een game naar Vulkan kan porten waarom zijn er dan op dit moment zo weinig Vulkan games aangekondigd
Om dezelfde reden dat 1 ontwikkelaar ook Flappy Bird kan maken terwijl er een heel team nodig is voor Flight Simulator.

En omdat moderne games iets (ietsjes maar!) meer doen dan alleen domweg polygonen tekenen met een standaard belichtingsmodel ;) Per pixel-belichting met verschillende modellen om een realistische weergave te krijgen van materialen zoals stof / huid / steen / gras / plastic / etc., normalmaps, procedurele textures, voorberekende data waar shaders mee om kunnen kunnen gaan, enz. En dan heb ik het nog niet eens gehad over de manier waarop de data richting de GPU wordt gepushed. Quake 1 heeft geen multithreading nodig. Moderne spellen hebben er daarentegen erg veel aan.

Had ik het al over productiecode vs democode? Of spaghetti vs lasagna?

Daarom dus.
Das wel een beetje vies van Apple. Maar hoe is de omgekeerde situatie? Ondersteunen de developers Metal wel? Ik had er een tijdje geleden iets over Metal-API gelezen, maar verder niets meer van gehoord. Ik neem aan dat het net als DirectX enkel werkt op het eigen platform?

typo's :Y)

[Reactie gewijzigd door !nFerNo op 25 juli 2016 20:35]

Ik denk dat een belangrijk signaal is, is dat cruciale personen in de spelindustrie, zoals Axel Geitning, Tim Sweeney, Gabe Newell, Alan Ladavac, Brad Wardell hun steun voor Vulkan hebben uitgesproken, terwijl zulke steunverklaringen voor Metal schiteren door afwezigheid.

Misschien dat sommigen Metal nog zullen ondersteunen om hun Apple-gebruikers het leven iets makkelijker maken, hoewel ik daar weinig daden zie. In ieder geval Alen Ladavac heeft zich expliciet uitgesproken tegen het ondersteunen van Metal, zolang OpenGL werkt ondersteunen ze Mac, en anders is het jammer voor Apple.
Achtergrond: ik kom uit de industrie van GFX/Compute APIs.

Metal wordt wel degelijk gebruikt, echter op een manier die hoort bij een "Gij zult onze API gebruiken en geen ander": als allerlaatste. Dit betekent dat de software eerst in bijvoorbeeld OpenGL compute, OpenCL en Vulkan (via SPIRV) wordt gebouwd, en daarna naar Metal wordt geporteerd. Je moet weten dat Metal een subset van OpenGL en OpenCL is, en het voelt dan ook als hacken om naar die API te porteren.

Er zijn enkele bedrijven al bezig een automatische vertaal-tool te genereren. Nog een signaal dat Metal slechts door weinigen als een echte oplossing wordt gezien.
Voor wie interesse heeft, vinx77 heeft het (volgens mij) over MoltenVK, deze krijgt overmorgen z'n launch: https://moltengl.com/moltenvk
Epic heeft op een Apple conferentie wel aangegeven dat de Unreal Engine ondersteuning zal hebben voor Metal en dat was vast niet de enige.

Ik denk dat alle bedrijven die werken aan high performance games (zoals first person shooters) voor iOS, die zullen allen ter zijne tijd overgaan op Metal.

P.S.: Metal wordt ook ondersteund in de Unity engine.

[Reactie gewijzigd door MacWolf op 26 juli 2016 05:02]

"Ik neem dat het net als DirectX enkel werkt op het eigen platform?"
Klopt
Gelukkig draait iedere Apple laptop en pc gewoon een echt OS, dus daar is Vulkan gewoon beschikbaar. Heb mijn USB stikkie met OS/X professional al klaar liggen... Installing Windows 10 :D
Nou, ik ben benieuwd naar de FPS-winst. :+

Wat is Apple trouwens weer vervelend bezig met hun eigen API. Ik snap het ook niet echt, dit maakt porten naar OSX (of hoe dat tegenwoordig heet) toch eerder lastiger?
Het woordje 'weer' kan je wel weglaten, komt een beetje als een flame bait over. Apple heeft recent pas Metal geïntroduceerd, en was ook voornamelijk op de mobiele markt gericht. Daarnaast heeft Apple altijd al OpenGL erg goed ondersteund, iets wat je van Windows niet kan zeggen, en bij Linux nog wel eens wat qua performance-wensen over laat (of, liet, het is een stuk beter de laatste jaren).

Windows was eigenlijk de enige die altijd maar weer met geheime API's kwam om te zorgen dat je niet naar een ander platform kon, dat de game markt zich haast wel aan Windows moest binden en met de Xbox hebben ze daar eigenlijk alleen maar het lijntje door getrokken, OpenGL is daar volgens mij niet eens een optie.

OpenGL en Vulkan zijn leuk qua cross-platform support, maar qua geld en tijd winnen ze niet om dat de tooling en workflow daar nou eenmaal niet op afgestemd is/was. OpenGL is met de opkomst van mobiele apparaten een stuk beter geworden om dat Windows daar nagenoeg niks betekent, en DirectX daarmee geen optie is. Andere API's waren er niet, of nauwelijks, en dan blijft OpenGL (en OpenGL ES) over. Om dat er niks voor mobiele GPU's is qua Low-Level globale API heeft Apple toen Metal gemaakt, en om dat Apple alles nogal cross-device bouwt is dat ook meteen voor OSX beschikbaar, zij het met wat aanpassingen om desktop en laptop type hardware infrastructuur te ondersteunen.

Als we kijken naar nog een alternatief, Mantle, is de vraag niet zo zeer of deze API's op den duur gaan winnen, maar eerder wanneer. Mantle zelf is niet heel zinvol om dat het maar voor 1 Fabrikant is, en dus niet op mobiele hardware, laptops en desktops gelijk te trekken is. Maar er is zeker vraag naar low-level API's, die niet gebonden aan specifieke hardware en software (OS) werkt, zonder beperkingen, overhead of lock-in te forceren.

We zijn van ruwweg twee (OpenGL en DirectX) naar een setje opties gegaan die zowel specialisatie als bredere onafhankelijke hardware toegang mogelijk maken, waarbij we waarschijnlijk over een paar jaar weer een merge of selectie zien van wat verder gebruikt zal worden.

Mantle, Vulkan, Metal, OpenGL (ES), DirectX, OpenCL, CUDA, het zijn diverse opties om je software goed gebruik te laten maken van de GPU, voor graphics en GPGPU taken. Dat er een paar af gaan vallen is wel zeker, hoewel je natuurlijk ook kans hebt dat het een tweedeling wordt tussen verdor-gebonden systemen en globale systemen, waarmee je zowel OS vendors als hardware vendors hebt aan een kant, en Vulkan, OpenGL en OpenCL aan de andere kant.
Mantle is dismantled (:+), daar heb je nu Vulkan voor, waar AMD met Mantle een flinke basis voor heeft gelegd. Dus dat is geen valide alternatief meer.
Nu nog CUDA weg en dan komen we bij de corporate stokpaardjes (Metal en DirectX). Hopen dat PowerVR en de rest van de veel voorkomende mobiele GPU's niet ook nog met hun eigen extra stoere graphics API's komen.
Correctie op je verhaal: Apple's ondersteuning voor OpenGL was grotendeels een teleurstelling. Heeft altijd achtergelopen ten opzichte van de officiele specificatie en performance is nooit zo goed geworden als bijvoorbeeld in Windows - verre van.
Het grote voordeel van Vulkan is dat het cross-platform is en nog steeds extreem goed performt. Je hoeft iets niet helemaal te porten naar een ander OS vanwege de API. Anders moet ik een versie voor Windows maken met DX12, MacOS met Metal etc.
Dat voordeel valt nogal tegen , je klink alsof je voor crossplatform klaar bent met vulkan alleen . Elke console heeft zijn eigen API dus voor crossplatform voor grote studio op huidige en vorige gen consoles heb je al handvol API nodig
Xb PS Nintendo ,
Met Vulkan dek je linux en windows alleen .
Voor Mac heb je dan Metal nodig.

Waarbij de grotere studio main target console zijn en met Xbox toolchain ook windows met DX stuk toegankelijker is.
Kleinere studio die beperkt zijn kwa simultaan releasen pakken de Xbox en windows zonder PS

De professional moet sowieso de API voor de grotere platformen kennen . Maar als je begint begin je met een van meest toegankelijke . Ik ben voor DX
Ik denk dat je je lage scores krijgt omdat je bijdrage vol onzin logical zit. Bijvoorbeeld dat je stelt dat, omdat bijna alle iOS-spellen Metal gebruiken, er geen reden is om Vulkan te willen. Ik zie het verband niet tussen A en B en kan je zo al een reden geven waarom te wel Vulkan wilt: Dan hoef je je Android-broncode niet opnieuw te schrijven als je je spel ook op iPhones wil uitbrengen.

Evenmin klopt de logica dat het, omdat Apples computers niet gericht zijn op het spelen van spellen, niet de moeite waard is om spellen op OS X uit te brengen. In tegendeel:Er wordt juist vrij veel gespeeld op Macs en het ontbreken van Vulkan daarop raakt het plezier van Mac-gebruikers.

Als je mensen die daarop terecht modereren dan ook nog voor "fanboy" gaat uitmaken...
Toch heeft hij wel een punt. Logisch discutabel maar wel on topic. Apple zit zelf in de vulkan groep, ik vind het ook vreemd dat OSX (voorlopig) geen support krijgt. Dat is erg onhandig met porten.

Anderzijds wordt metal volop gebruikt. En blijkt het efficiënt. Vulkan werkt voorlopig alleen met Doom en heeft het alleen asynchronious compute met AMD kaarten.

Wat mij betreft +1
Ehhm, macs gebruikten gewoon Opengl voor ze overstapten naar Metal. (Duh!)

En het gaat om meer dan ios. Macos wordt ook door Apple's 'Metal only' beleid beinvloedt.

[Reactie gewijzigd door parryfiend op 25 juli 2016 22:16]

Klopt, maar de versie van OpenGL die Apple ondersteunt is versie 4.1 uit 2010. Sinds die tijd hebben ze geen updates meer gedaan aan hun OpenGL implementatie. We zitten ondertussen al op versie 4.5!

Dat heeft als consequentie dat een groot deel van de nieuwe Compute Shader functionaliteiten die in latere versies van OpenGL zijn toegevoegd niet beschikbaar zijn op MacOSX.

D'r is een hele berg topics op het Elite Dangerous forum van Mac bezitters die boos zijn dat Frontier Developments de Horizons uitbreiding niet op Mac uitbrengt, terwijl de reden daarvoor is dat Horizons zwaar leunt op Compute Shaders voor het genereren van planeten opervlaktes en dat ontbreekt nou net in de OpenGL versie die Apple in MacOSX ingebakken heeft.

Voor een kleine developer als FD is het economisch niet zo zinvol om alles naar Metal te gaan porten want met OpenGL kunnen ze veel meer platformen bedienen dan met het Apple Only Metal.
Precies mijn punt (zie eerder in topic). The dev community kiest dan toch OpenGL of Vulkan terwijl Apple krampachtig vast blijft houden aan Metal.

Ik verwacht dat deze trend zich zal voortzetten indien Apple blijft bij Metal only.

[Reactie gewijzigd door parryfiend op 26 juli 2016 10:10]

Ik ga heel ver met je mee, maar je hebt één ding mis: OpenGL gaat al heel lang mee en word al sinds voor dirextx gebruikt voor games.

Vulkaan is net nieuw, dus het is afwachten of het omarmd gaat worden of niet.
Begrijp me niet verkeerd Vulkan zal vast wel leuk zijn maar geen enkele TopGame AAAA+ gebruikt het. Zelfs AMD Mantle werd eerder geadopteerd dan OpenGL.
Nog afgezien van je andere puntjes met soms wat vreemde logica (ik heb je originele post overigens een +1 gegeven want wel on-topic), is dit statement gewoon pertinent niet waar. Het artikel zelf spreekt al over de nieuwe Doom dat tegenwoordig Vulkan ondersteund en als dat geen AAAA+ game is dan weet ik het ook niet meer. Andere games met (aankomende) ondersteuning voor Vulkan zijn The Talos Principle, Ashes of the Singularity en Shadow Warrior 2. Misschien niet de meest toonaangevende triple A titels in jouw ogen, maar ook zeker geen pixelige indie games.
Ik ben het met je eens, tot vlak voor het einde. Je zegt dat geen enkele populair videospel Vulkan gebruikt, en dat Apple daarom weinig reden heeft om Vulkan te ondersteunen. Maar daar zou ik tegenin brengen dat een API wel eerst beschikbaar moet zijn om mee te ontwikkelen, wil je ook software zien die er gebruik van maakt.

Stel nou dat ik een geweldig mooie API zou maken, die alles 10x beter maakt. Als mijn API slechts op de Nokia 3100 draait, dan is het niet echt verwonderlijk dat er geen grote spellen mee ontwikkeld worden. Het verschil met Vulkan is echter dat behoorlijk veel hardware- en softwaremakers wél ondersteuning inbouwen. Het is dan vervelend als een van de (vooral op de mobiele markt) grote spelers achterblijft. Dat ze het recht hebben er niet aan mee te doen, daar heb je gelijk in. Maar om nou te zeggen dat het beter (of even goed) is als zo'n bedrijf een eigen API blijft promoten is niet waar denk ik. Hoe geweldig zou het zijn geweest als bijna alle Windows spellen gewoon op de Mac en Linux waren uitgekomen, omdat Microsoft aan OpenGL had gewerkt in plaats van DirectX.

Het komt er uiteindelijk op neer dat consumenten bedrijven niet afstraffen die teveel handelen in het voordeel van de aandeelhouders en ten koste van de consument. Microsoft en Apple kiezen er liever voor om te proberen exclusieve titels binnen te halen, maar dat is voor de consument helemaal niet fijn. Bekijk het voorbeeld van Halo, dat oorspronkelijk een Mac-spel zou zijn, tot Bungie door Microsoft gekocht werd.
Triple A studio hebben grote teams , vaak appart engine team die engine opgewaardeerd wordt na elke released game. En onder productie nog wat iteraties krijgt. Grote budged games verreisen al snel meerdere grote markten . En crossplatform is een production detail dat ingecalculeerd wordt en dat is voor grote studio al geen probleem .
Het zijn de kleinere studio die met hun eigen engines die meeste last hebben van API wild groei . Gross dat voor licenceerbare multiplatform engines gaat heeft er nog minder last van .
Daarnaast hebben kleine producties al die grote markten niet nodig . En goed mogelijk om te focusen eerst op die platform waar meest bekend mee bent . En platformen na mekaar uit te brengen ipv alles synchrone .
Grote triple A studios gaan eerst voor de grootste
Dat zijn consoles .
DirectX X xbox api.
PS API
PC windows DX API of Vulkan of OpenGL
Dat zijn de grootste
Dan wordt het kleiner en dan ook optie die vaker niet genomen wordt .
Dus triple A engine heeft op zijn minst de Xbox Windows en PS API nodig.
Dan ook Nintendo API
Verre optie zijn

Linux opengl vulkan
en Mac opengl en metal.

De low level API de vraag was er al langer , Mantle kwam er eerst . Hardware was er ook al veel eerder. DirectX12 volgde . Doel van Mantle bereikt. Vulkan als hekke sluiter . Beide gebaseerd op Mantle waarbij Vulkan eerlijk en openlijk ook de credit van vulkan devs, naar Mantle & AMD.


Zelf meer gericht op DX12 als 1 man hobby programmer richt ik mij op mijn developer platform windows 10 ook als release platform. De reden is mijn history vanaf DX2 t/ m verse DX12.
Voor zeer kleine projectjes ben je meer met de API bezig aangezien dat aandeel groot is.
Maar voor grote producties is de render API een implementie detail ergens in systeem en hardware abstraction layers .
En is engine al groot de production tool chain en content productie flow is dan veel belangrijker dat grote team productief kunnen zijn.

Zoals mijn history met Elke DX
Heeft IDsoft dat met OpenGL hun code base en engines komen daaruit voort en engine worden niet van scratch ontwikkeld dat gebeurt alleen aks voor het eerst aan begint voor IDsoft is dat de IDtech1 daarna heb je code base allerlei modules en componenten dat zijn bij grote engines feature rijk en data driven een paar dozijn.
Dus dat houd in dat idtech 2 tot IDtech 3 er genoeg code is van componenten uit vorige engine .
Een robuste IO routine vervang je niet als die nog voldoet aan de eisen voor de volgende engine.
Dat is meer iets als de oude OS API voor IO is depricated en vervangen is dan is tijd voor nieuwe.
Je hebt wel gezegd dat het niet de moeite waard is om een API op OS X te hebben. Dan neem ik aan, en inderdaad die aanname is geheel aan mijn zijde, dat je ook bedoelt dat het niet de moeite waard is om spellen op OS X te hebben. Immers, spellen hebben API's nodig, dus als je wel spellen op OS X wilt hebben zul je ook in API's moeten voorzien.

Het belang van Vulkan op iOS gaat verder dan of het de consument uitmaakt of een spel Metal danwel Vulkan gebruikt. Zoals je wellicht weet is Android t.o.v. iOS aan de winnende hand. Dat betekent dat als een programmeur moet kiezen tussen beide, hij voor Android en dus Vulkan gaat kiezen. Op dit moment is iOS nog dusdanig groot dat de afweging van de extra moeite die nodig is om de broncode later naar Metal te herschrijven, versus de opbrengsten, gunstig uitvalt. Zet de trend zich evenwel door, dan kan het zijn dan spelontwikkelaars de moeite niet meer nemen om "dat lastige Metal" te gaan ondersteunen, wat zal leiden tot een afname in de hoeveelheid spellen die op iOS uitgebracht worden.
Android tov iOS aan de winnende hand?

-In percentage van de markt absoluut.
-In omzet en winst voor Google cq Android device fabrikanten? Absoluut niet.
-In omzet en winst voor app makers? Absoluut niet.

De vergelijking die je maakt is zinloos en gaat mank omdat ie voorbij gaat aan alle financiele relevante factoren.

Buiten dat ben ik een voorstander van een open standaard en zou ik het een goede zaak vinden als Apple Metal open source maakt, als het dat niet al is en daarnaast Vulcan implementeert.
Hier ben ik het mee eens. Juist voor de (laten we zeggen) AAA mobile games is de kans groter dat het spel in eerste instantie voor iOS met Metal geschreven wordt en later met Vulkan geport wordt naar Android. Immers: app makers verdienen nog steeds het meest aan iOS.

Aan de andere kant, engines zoals Unreal en Unity ondersteunen al Metal (naast OpenGL en vast ook Vulkan) en de meeste bedrijven zullen hun spellen op basis van die engines schrijven. Dat maakt het poorten dus een stuk eenvoudiger.

[Reactie gewijzigd door MacWolf op 26 juli 2016 09:25]

Ja, prachtig dat Apple het beter denkt te weten met Metal, maar wat heeft dat er in godsnaam te maken met het buitensluiten van een concurrerende API op je platform? En je verdedigt Apple door de vergelijking te trekken met MS en DX, maar ondertussen vermeldt je niet dat Vulkan tenminste wel op MS zijn platform kan concurreren met DX,.

En beter is niet noodzakelijk:
  • 2 a 3x hetzelfde werk doen door 3 low-level APIs te bouwen
  • dat devs nu ook 2 a 3x hetzelfde werk moeten verrichten om te porten
  • 2 a 3x markt versplintering
Ik vind het best als iemand het in de industrie beter weet, maar deel je project dan met de rest, of accepteer op zijn minst concurrentie op je platform.
Ze weten het zeker beter , in grote producties is API al helemaal geen probleem .
Team van 100+ heb je voor engine team van dozijn ten minste 1 metal guru nodig. Gross van de kleinere productie gebruiken licenceerbare engines . Waarbij men ook voor alle platformen van belang dus voor dat grotere engine team ook een Metal guru en die studio merken er eigenlijk niet veel van.

Kleine studio onafhankelijk met fan dev voor API kan zijn favo API kiezen en exclusive daarvoor gaan. Is dat Vulkan houd in studiootje dat exclusief voor linux en optioneel windows kan developen. De big studio en hun publisher met triple A producties is daar geen plaats voor die kijken naar de grootste markten om die grote investeringen te kunnen terug verdienen.

Als platform klote is om voor te programmeren maar groot is is dan gaat men er toch voor.
De PS3 Cell SPE PPE asunc multitreaded 1+7 core.
Je heb dan een PS3 guru in engine team nodig.
Quake draait zo'n beetje overal wel op inmiddels dus da's niet echt nieuws meer wat mij betreft. Leuk dat het gelukt is in het geval van de Vulkan-api, maar voor iemand die bij ID werkt waarschijnlijk een eitje.

Overigens wel jammer dat we nu dus Vulkan erbij krijgen, terwijl Mantle er al was en Apple heeft zijn eigen api en wil de rest niet ondersteunen. Ja, dat zet echt zoden aan de dijk! 8)7
Maar Vulkan is crossplatform & cross GPU(als nvidia niet te lui is). en draait zelfs op Android. in mijn ogen alles wat we nodig hebben. Als devs massaal op vulkan overstappen is er niets aan de hand.
Als NVidia niet te lui is? NVidia had 1 of 2 dagen nadat de Vulkan 1.0 specificatie officieel uit kwam ondersteuning in hun drivers. AMD kostte dat een week en de driver had het label 'beta'. Ik had het graag andersom gezien, maar dit was afgelopen februari de praktijk.

@SomerenV: de Mantle specificatie die uit de koker van AMD kwam is door de Khronos Group en hun leden (o.a. Valve, Intel, AMD, NVidia, Epic en vele anderen) gebruikt als fundering voor Vulkan. Mantle is zogezegd het ei waar de kip die Vulkan heet uit is gekomen. Nu nog een implementatie maken van de Mantle specificatie heeft dus geen zin meer, de wereld is verder gegaan met Vulkan.
Ik doelde op de 1060 die bagger vulkan support heeft
Is dat zo? Heb je een bron? Ik ben namelijk een Linux gamer en was van plan binnenkort een nieuw systeem te kopen met een 1060 er in, maar dat heeft natuurlijk weinig zin als de Vulkan support slecht is want dat is nu juist waar Linux gamers het in de toekomst van moeten hebben.
reviews: Nvidia GeForce GTX 1060 review: op scherp in het midrange-segment

Vulkan blijkt voor een behoorlijke stijging in framerates te kunnen zorgen, en levert op AMD-gpu's een 25 tot 37 procent hogere framerate op. De oude Nvidia Maxwell-gpu's hebben nauwelijks baat bij de nieuwe api, maar de Pascal-gpu's in de GTX 1070 en 1080 laten ook een stijging in framerate van 25 tot 30 procent zien. Je zou daarom ook verwachten dat de GTX 1060, die van dezelfde Pascal-architectuur is voorzien, het goed doet in Vulkan, maar dat blijkt niet zo te zijn, en de winst bedraagt slechts enkele procenten. Wellicht moet Nvidia nog wat aan zijn drivers sleutelen om de winst in Vulkan ook bij de GTX 1060 te realiseren.

Al zou hij volgens de specificaties het wel moeten supporten. Had ook nog ergens gelezen dat de gtx-1060 geen vulkan support zou hebben. Vandaar dat ik lui zij.
Ik zal de tweakers review nog eens uitgebreid doornemen dan. De 1060 heeft wel degelijk support voor Vulkan, dat weet ik zeker. Dat de 1070 en 1080 het beter doen verbaast me niets, maar die kaarten vind ik net even te duur.

Zoals ik elders op deze reactie pagina al een keer heb laten vallen heeft AMD de betere hardware voor wat de Vulkan API biedt. Ik zou dan ook graag een AMD kaart kopen, maar hun drivers onder Linux zijn van dusdanig slechte kwaliteit dat dat gewoon geen optie is.
Ik verbaas me nog steeds dat het vooroordeel over AMD+Linux er zo ingebakken zit. De support voor AMD kaarten onder Linux is naar mijn mening op dit moment beter dan die van Nvidia. Check Phonorix maar eens.
Zie: www.pcgameshardware.de/Do...hmarks-Frametimes-1202711/
Verwacht wel dat dit bij de eerst volgende driver gefixed zal zijn.
Zeg Axel, Quake 1 op Linux hadden al, je moet Doom 2016 op Linux zetten. ;)
Yes please! Maar dat gaat waarschijnlijk niet gebeuren. Niet omdat het technisch niet mogelijk zou zijn, de engine ondersteunt namelijk al Vulkan als renderer en id Software kennende hebben ze weinig tot geen platform specifieke code en middleware gebruikt, maar omdat publisher Bethesda in het verleden al meerdere malen heeft bewezen niets om Linux gamers te geven en bijvoorbeeld dus ook SteamOS lekker aan het negeren is.

Daarnaast is er nog die vervelende Denuvo copy-protection die op Linux niet werkt of in ieder geval niet geport is, waar ik stiekem eigenlijk wel blij mee ben.
Oh, apple wil geen vulkan ondersteunen?
Dat wist ik nog niet. Sluiten ze zichzelf weer buiten.
Ik kan het nog wel zien gebeuren dat er games komen die alleen Vulkan en DX12 ondersteunen.

Verder wel grappig dat de dooms en de quakes nog steeds geport worden. ;)
Het irritante aan Apple is dat ze vaak nog een grote meute mensen hebben die ze steunen ook. Alles wat Apple doet is beter "omdat... ".

Jammer, want Apple is het buitenbeentje vwbt het houden aan standaarden.
Jammer, voor mijn gevoel zijn ze het buitenbeentje aan het worden op gebied van standaarden.

[Reactie gewijzigd door Michaelr1 op 25 juli 2016 21:32]

Die laatste regel is een beetje kort door de bocht.

ze hebben zoveel standaarden ondersteund, je hebt geen idee. 1 voorbeeld: ze waren de eerste met USB in hun pc's.
En weet je wie daarvoor verantwoordelijk is? Microsoft. Er wordt gezegd dat toen Steve Jobs terugkwam bij Apple, hij Bill Gates op belde met het bericht dat hij zijn hulp nodig had. Microsoft heeft toen toegezegd de iMac te gaan ondersteunen met ondermeer Office, in ruil dat Apple USB zou omarmen.
Dat lijkt me duidelijk een broodje aap verhaal aangezien MS Office in 1985 voor de Mac uitkwam, twee jaar voordat de Windows versie uitkwam en 13 jaar voordat de eerste iMac uitkwam.

Apple had gewoon genoeg van al die verschillende legacy poorten en wilde alles onderbrengen onder één poort. Het is ze uiteindelijk gelukt maar niet zonder problemen. USB was nog niet populair en USB randapparatuur was nog schaars. Zo bestonden er nog geen USB muizen en moesten ze die vreselijk Apple puck muis maken en duurde het nog een paar jaar voordat USB een beetje gangbaar werd op printers.
Die laatste regel is een beetje kort door de bocht.

ze hebben zoveel standaarden ondersteund, je hebt geen idee. 1 voorbeeld: ze waren de eerste met USB in hun pc's.
Toen Apple het moeilijk had wel, maar tegenwoordig gedragen ze zich precies zoals MS dat in de jaren '90 deed. Telkens hun eigen ding doen en zich niet markt-conform gedragen.
Het ligt iets anders. Juist door zich niet markt conform te gedragen werden ze groot of werden hun ideeën snel opgevolgd. De eerste die floppy in de ban deed. De eerste die dvd-speler in de ban deed. De eerste die bedacht dat we misschien wel een hoge resolutie wilden. (Zie hoe dat over de top is gegaan bij andere merken). Enzovoort.
Alleen maken ze nu misschien een paar verkeerde keuzes.
hier zijn wat github stats van deze man zijn werk:

Showing 134 changed files with 5,855 additions and 17,532 deletions.
128 commits, 16 dagen geleden begonnen met de eerste commit.
Bij de titel dacht ik heel even dat er a la Battlefield 1 een nieuwe Quake zou komen, die dan toevallig Quake 1 gaat heten. Maar neen, het gaat hier om het klassieke origineel. Tja.

Dit was de eerste game waarvoor ik dedicated 3D hardware heb gekocht destijds (een Diamond Stealth II S220). Als deze port af is ben ik ergens wel benieuwd naar welke framerate ik dan haal op mijn huidige setup. :P
Goede oude tijd vroeger met Glide :)

Dit is een nieuwe fase daarvan

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True