Quake 1 is geport naar Vulkan

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.

Door Krijn Soeteman

Freelanceredacteur

25-07-2016 • 20:04

85

Reacties (66)

66
65
49
10
1
7
Wijzig sortering
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 22 juli 2024 14:42]

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 22 juli 2024 14:42]

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 434365 op 22 juli 2024 14: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 22 juli 2024 14:42]

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 22 juli 2024 14:42]

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.
.oisyn Moderator Devschuur® @dmantione25 juli 2016 21:53
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.
.oisyn Moderator Devschuur® @dmantione25 juli 2016 22:14
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.
.oisyn Moderator Devschuur® @SwiftPengu26 juli 2016 11:36
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 22 juli 2024 14:42]

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?
Anoniem: 112755 @zonoskar26 juli 2016 00:09
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 22 juli 2024 14:42]

.oisyn Moderator Devschuur® @Superstoned25 juli 2016 21:46
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 22 juli 2024 14:42]

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.
.oisyn Moderator Devschuur® @et36s26 juli 2016 14:06
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 22 juli 2024 14:42]

Anoniem: 505316 @Michaelr125 juli 2016 22:03
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 22 juli 2024 14:42]

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 22 juli 2024 14:42]

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 22 juli 2024 14:42]

"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.
.oisyn Moderator Devschuur® @johnkeates25 juli 2016 22:30
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.
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.
Anoniem: 84213 @loki50426 juli 2016 15:09
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...marks-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 22 juli 2024 14:42]

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.