Ondersteuning Vulkan-api komt na uitstel eind juli beschikbaar in CryEngine 5.4

Crytek heeft bekendgemaakt dat versie 5.4 van de CryEngine ondersteuning krijgt voor de Vulkan-api. De nieuwe versie moet eind juli klaar zijn. Vulkan-ondersteuning was aanvankelijk gepland voor november vorig jaar.

Crytek meldt dat delen van de Vulkan-implementatie al te zien zijn in de code op Github, maar dat deze nog niet actief is. De ontwikkelaars voeren nog verbeteringen door om de software stabiel te krijgen voor de release eind juli. In september vorig jaar kondigde Crytek de komst van ondersteuning voor de Vulkan-api aan. Het plan was dat de ondersteuning er al in versie 5.3 zou komen, maar dat bleek onhaalbaar.

Vulkan is een grafische api die grotendeels gebaseerd is op AMD's Mantle. Net als Mantle en DirectX 12 is deze api gemaakt om minder overhead te hebben dan andere api's, zoals OpenGL en oudere versies van DirectX. Onder meer pc-games en mobiele Android-games kunnen Vulkan gebruiken.

Uit de roadmap van Crytek blijkt dat ondersteuning voor multi-gpu in DX12 beschikbaar zal zijn in CryEngine 5.5, de versie die in augustus uit moet komen. Aanvankelijk was ondersteuning hiervoor gepland in februari van dit jaar. Bij multi-gpu in DX12 kan de software de rekenkracht combineren van verschillende gpu's, zonder dat deze in een crossfire- of sli-opstelling zijn geplaatst.

Reacties (68)

[Origin64]

Aan de ene kant leuk, al die nieuwe api's', aan de andere kant levert het wel een hoop extra werk op. Ik zie toch meer in opengl op de lange termijn dan in het verzinnen van nieuwe dx-alternatieven.

[Reactie gewijzigd door Origin64 op 24 juli 2024 16:29]

[SG]

Waar DX12 naast DX11 komt als directere API en DX11 als meer abstractere API.
Vervangt Vulkan OpenGL wat voor grotere devs een gedrocht is geworden. Met vele extenties waar men rekening mee moet houden.

OpenGL wordt geprezen door het eenvoudig opzetten van code in hobby projectjes.
Maar de game industrie heeft op productie niveau waar men uiteraard de meer moderne features van hardware wilt benutten er veel werk aan.
John Carmack zou op paar jaar geleden al liever voor DX gaan omdat het veel betere API is vanuit development perspectief.
Maar ja hun legacy codebase moet dan omgegooid worden en die taak is een te grote .

Dus Vulkan is grote en belangrijkere evolutie kwa API als het lost ook developer specifieke problemen op. En is dus op dat gebied anders dan OpenGL.

[Origin64]

Een nieuwe opengl versie zou die problemen ook op kunnen lossen, de reden dat vulkan niet opengl 5 heet ofzo is dat het lower level werkt. je zou kunnen stellen dat de verhouding tussen dx11 en 12 dezelfde is als die tussen opengl en vulkan. met de kanttekening dat met opengl werken meer werk is voor grote studios dan met dx11 werken.

volgens mij werken veel studios met directx omdat ze dan hulp krijgen van amd/nvidia om hun games te optimalisen in zo'n twimtbp programma

[Reactie gewijzigd door Origin64 op 24 juli 2024 16:29]

[DaVince21]

> Een nieuwe opengl versie zou die problemen ook op kunnen lossen

Dat is dus niet zo. De ontwikkelaars van Vulkan waren er vrij vroeg al uit dat de manier waarop OpenGL fundamenteel in elkaar zit niet meer gangbaar is. Dat is de hele reden dat er geen OpenGL 5 was ontwikkeld maar juist iets als Vulkan. Er zijn duidelijke fundamentele verschillen.

[Origin64]

wat zijn die verschillen dan? behalve dat vulkan lower level is. dat vind ik juist interessant om te weten. wat is er in opengl zo slecht en waarom kan dat niet worden verbeterd? volgens mij gaat het er niet om dat opengl 'niet gangbaar' is, maar dat khronos een graantje mee wou pikken van de shift naar lower level apis en ze zagen dat er een gebrek was aan een cross platform oplossing in die markt. zodra de cirkel weer rond is en we weer bij higher level uitkomen, kunnen ze de opengl naam weer afstoffen.

dat vulkan er is, betekent niet dat er niet ooit een opengl 5 komt. het is anders. daarom heeft het een andere naam. anders hadden ze het gewoon opengl next kunnen noemen, toch? als ze zeker niet meer met opengl 4.5 verdergingen.

[Reactie gewijzigd door Origin64 op 24 juli 2024 16:29]

[rbr320]

Ik heb het nieuws omtrend Vulkan redelijk goed gevolgd toen de API nog in ontwikkeling was en je hebt inderdaad gelijk dat het niet uitgesloten is dat er ooit nog een nieuwe versie van OpenGL komt. Vulkan is als low-level API specifiek geschikt voor het ontwikkelen van game engines, voornamelijk die van de grote jongens (EPIC's Unreal Engine 4, CryTek's CryEngine, Unity3D). Indie developers zullen waarschijnlijk altijd wel OpenGL blijven gebruiken in hun kleinere games, tenzij ze natuurlijk een van de bovenstaande engines gebruiken.

OpenGL is helemaal niet zo obscuur als sommige gamers lijken te denken. In de CAD en "medical imaging" wereld is het namelijk al tientallen jaren de de facto standaard. Dat heeft echter wel als gevolg dat OpenGL veel legacy met zich mee draagt waar je niet makkelijk vanaf komt. De API heeft heel veel verschillende functies en extensies om ongeveer hetzelfde te doen, iets wat voor game developers maar lastig is. Om te kunnen blijven concurreren met Microsoft's DirectX en daarmee ook meteen games makkelijker cross-platform uit te kunnen brengen is er in de afgelopen jaren door diverse partijen, waaronder Valve, gesproken met de Khronos groep over het opschonen van de API. Uiteindelijk bleek het makkelijker te zijn om AMD's Mantle te pakken en door te ontwikkelen tot een volwassen low-level graphics API.

Overigens is er geen sprake van "een graantje mee pikken" door de Khronos groep. Dit is een non-profit organisatie die een flink aantal open standaarden beheert en ook bedenkt, maar ze hebben verder geen enkel commercieel belang. Het echte werk wordt gedaan in commissies die bestaan uit leden van de Khronos groep. Daar zitten uiteraard partijen tussen die waarschijnlijk wel belang een commercieel belang hebben deze open standaarden.

[SG]

Ja chronos Vulkan team heeft ook publiekelijk AMD bedankt voor de Mantle API donatie aan hun.
Zij hebben niet beleid van bedrijf dat publiekelijk hun prestige of imago hoog moeten houden voor de impressie dat ze alles zelf ontwikkeld hebben. De schijn van innovatie voorziener.
De vele geruchten dat DX12 ook flinke doorontwikkeling van mantle is maar zodanig gerefactored zo ook documentatie dat Mantle er niet meer inziet.

[Origin64]

de organisatie heeft toch belang bij hun eigen voortbestaan, ook al maken ze geen winst, er wordt wel loon betaald. (of is het allemaal pro deo?)
ook is het leuk om op je cv te zetten dat je aan vulkan hebt gewerkt. mensen die bij khronos werken hebben best commercieel belang.

verder dank voor de uitleg

[SuperDre]

Nou, vond zelf opengl verre van eenvoudig, enige voordeel was dus het multiplatform zijn, maar precies zoals je zegt, wilde je wat beter de moderne capaciteiten van een gpu gebruiken, kwam je bij extensies terecht die weer deels gpu-leverancier specifiek waren.

[Verwijderd]

Ik zie toch meer in opengl op de lange termijn

Die tekst hoor ik nu al bijna 25 jaar. Ik denk dat we ondertussen realistisch genoeg mogen zijn en toegeven dat dat niet gaat gebeuren.

[Origin64]

nou, vulkan is van dezelfde organisatie die opengl nu onderhoudt, en het werd eerst 'opengl next' genoemd, dus het is soort van aan het gebeuren. maar op de lange termijn zie ik low level apis niet echt werken. het werkt voor consoles, maar op pc zal het over een paar jaar al veel werk zijn om voor alle gpus die het ondersteunen de juiste code te schrijven, als we een paar gens verder zijn. misschien komt iemand dan weer op het idee een meer high level api uit te vinden.

[Reactie gewijzigd door Origin64 op 24 juli 2024 16:29]

[Verwijderd]

Je moet toch echt een keuze maken:

Of Vulkan is een directe afgeleide van OpenGL
OpenGL als highlevel api is beter dan de lowlevel api Vulkan

Het maakt mij niet uit wat je kiest, omdat onze meningen er niet echt toe doen over wat de toekomst gaat brengen, maar het is wel netter als je wat consequenter bent.

[Origin64]

vulkan is een lower level afgeleide van opengl. opengl is niet 'beter' dan vulkan, het is anders, en op de lange termijn zie ik meer in high level dan in low level. met de tijd zal vulkan of een break moeten hebben waarbij er niet meer voor oudere hardware wordt geoptimaliseerd, of het wordt steeds meer werk voor mensen die engines maken om al die hardware op low level te ondersteunen. daarom is high level mijns inziens 'beter', de graphics die met low level mogelijk zijn, die zien we dan over 2 jaar wel. scheelt een hoop werk, dan zijn de engine licenties goedkoper en kan er meer budget aan gameplay worden besteed.

[Reactie gewijzigd door Origin64 op 24 juli 2024 16:29]

[SG]

Vulkan is directere afgeleide van AMD Mantle.
Ze zijn nogal dankbaar en blij met de donatie van Mantle API source code.
Voor hun is het een vliegende start.

[Lawrentium]

Vulkan is veel meer dan alleen een DirectX (of eigenlijk Direct3D) alternatief. Het is een serieus alternatief voor OpenGL. Het is sneller dan OpenGL, en het programmeren/optimaliseren is ook nog eens een stuk makkelijker.

[dmantione]

Dat laatste is zeker niet het geval: Vulkan vereist vanwege het low-level karakter ervan veel meer programmeer- en optimalisatiewerk.

[Verwijderd]

Ik denk dat hij het wat ongelukkig geformuleerd heeft. Vulkan is makkelijker te optimaliseren voor applicatie ontwikkelaars dan OpenGL. OpenGL is namelijk niet/nauwelijks te optimaliseren, behalve in de drivers.

[rbr320]

Dat is niet helemaal waar. Momenteel zie je in de benchmarks van games die zowel een OpenGL renderer als een Vulkan renderer hebben dat OpenGL eigenlijk altijd sneller is. Het is namelijk wel degelijk te optimaliseren, alleen moet dat zowel in je eigen code als in de driver gebeuren en heb je er als developer dus minder controle over. Uiteraard kan dit ook worden toegeschreven aan het feit dat Vulkan nog een erg jonge API is en ontwikkelaars er dus nog niet zo bedreven mee zijn.

Het idee achter low-level API's als Vulkan en Direct3D 12 is dat de driver veel eenvoudiger en kleiner is waardoor hij minder overhead met zich mee brengt. Dat heeft wel als gevolg dat de developer volledig zelf verantwoordelijk wordt voor het optimaliseren van zijn code. Goed voor grote game studios met veel ontwikkelaars in dienst, maar de indies zullen waarschijnlijk altijd OpenGL blijven gebruiken.

[SG]

OpenGL en Directx11 zijn extremer afhankelijk wat AMD iNtel nVidia met de driver doen. Vooral nVidia doet heel veel op driver niveau. Zelfs dat shader code vervangen wordt.
Bij driver releases krijgen populaire games een speedbump.

Gezien je met deze low kevel API nu GPU resources in eigenbeheer hebt.
Moet je dit werk nu zelf doen. Ipv van dat dat onder de abstractie valt.
Voordeel van de dev die weet goed wat de engine van API wilt en kan de gpu management daar op afstemmen. Dat zal inderdaad niet meteen vruchten afwerpen als het is ook leer procses van ervaring.
Die ervaring heeft nV ook niet zij werken vaak met gissen wat de dev wilt. Vangen vaak ook miss use en bugs op, op driver niveau. Niet elke Productie heeft nV mannetje te leen erbij. Of werkt met gameworks. Dat geld voor mantle Vulkan en DX12.

[Laurens-R]

Ik denk dat je stelling niet correct is.

Vulkan is min of meer DE opvolger van OpenGL. Het komt tenslotte van dezelfde groep als OpenGL en er is geen duidelijke roadmap voor de toekomst gedefinieerd voor OpenGL. Tevens is OpenGL een draak om mee te werken in multithreading scenario's en bied het geen perspectief voor de toekomst.

[dmantione]

Voor spelletjes is dat min of meer juist. OpenGL wordt echter veel breder ingezet en kan dan ook niet zomaar afgeserveerd worden. De Khronos-groep sluit niet uit dat er een OpenGL 5 komt, al zien ze momenteel geen reden om een nieuwe versie te definiéren.

Vulkan is evenwel ook breder inzetbaar dan alleen spelletjes, er gaan bijvoorbeeld al stemmen op om OpenCL bovenop Vulkan te gaan implementeren. Voorlopig zijn spelletjes alleen wel de enige toepassing van Vulkan.

[SG]

Vulkan is ook meer gericht op game industrie.
OpenGL is van oorsprong een API die in prof. Wereld wordt toegepast.
Na Glide kwam ook OpenGL als alternatief voor niet 3DFX hardware en er kwam uireraard ook Direc3D DX2. WinG was te beperkt.

[Origin64]

Ik zou dan wel willen weten wat er in opengl zo onhandig is dat het niet alleen nu moeilijk is om multithreading te gebruiken, maar dat dat ook niet verbeterd kan worden in een nieuwe versie.

[Laurens-R]

GlContext en het feit dat je die in elke thread moet synchronizeren. Dat is duur en onhandig. Je kan met job queues op de render thread het probleem soort van oplossen (maw je hebt 1 thread die al het opengl werk doet en andere threads geven die opengl thread instructies. dan vermijd je dure context synchronisatie) maar het blijft een bottleneck. Het hoort gewoon bij de manier waarop de api is opgezet. Die zal je fundamenteel moeten wijzigen om dat probleem te fixen. Dat hebben ze dan ook gedaan en het heet Vulkan. Daarin kan je gewoon op elke thread zonder problemen met de API werken.

[Reactie gewijzigd door Laurens-R op 24 juli 2024 16:29]

[Origin64]

en die multithreading implementatie van vulkan, is daarin inherent dat de api lower level moet zijn of zou het ook mogelijk zijn een higher level api te maken die even parallelliseerbaar is? (bijv. opengl 5)

[Reactie gewijzigd door Origin64 op 24 juli 2024 16:29]

[SG]

Ik zou mij niet zo fixeren op naam.
Die figure head AMD MS Chronos geven hun beestjes een naam.

MS had DX12 ook totaal nieuwe naam kunnen geven. Maar ja de naam heeft al Direct erin. En andere kreet voor directer?.

MS hebben uiteraard ook de nodige feedback van AMD. Niet alleen Chronos al is die door openheid natuurlijk publiek bekend. En uiteraard ook MS geprofiteerd van Mantle API.
De reden dat andere API relatief snel volgde en in alfa tijd de documantatie paste copy Mantle was.

Ipv wat OpenGL niet en wel kan ze gekapt met legacy spul . Dat is uiteraard vanuit die dev feedback. En dus door Developer feedback de overhaul API gemoderniseerd naar dev vraag en aan huidige hardware.
Dat heeft MS met DX10 ook gedaan, API ook flink overhoop gehaald. En met DX12 nog extremer.

Een nieuwe naam is meer iets van marketing. De stap is zo groot en de API zo anders dat een andere naam dan next opengl nummer te rechtvaardigen is.

Het nadeel van kiezen voor kreet en sequel nummering DX12 is een intentie van vervanging DX11. Wat dus niet de bedoeling is. Die deel markt van grote dev die de hardware ver willen pushen hebben een eigen versie die ze meer beheer geven over de hardware en daarmee grotere verantwoordelijkheid en dus ook meer werk en veel meer kennis benodigd. De grote deel van de markt blijft bij DX11.

Dus als zou je andere hogere versie opengl willen , je kreeg dan ook Vulkan voor games.
Misschien dat de OpenGL verder ontwikkeld wordt met nadruk voor prof.

Je op de commerciele tak grote contributie uit partnerschap AMD gputak met MS.
En in de open tak een grote sourcecode donatie van een partner. AMD met Chronos.

[Origin64]

Ik denk dat als grote devs een paar jaar bezig zijn om de hardware te pushen, dat een aantal optimalisaties die zij toepassen steeds meer gemeengoed worden en het daardoor loont ze ook in een andere laag te kunnen doen (bijv. video driver ipv api) waardoor we weer uitkomen bij higher level apis met minder en complexere calls.

[SuperDre]

Vulkan IS de opvolger van OpenGL.

[Origin64]

Het heette eerst ook opengl next, maar ik zie wel een verschil. vulkan is lower level dan opengl. ik had misschien kunnen zeggen: ik zie meer in een combinatie van beide. low level optimalisaties in de engine als de hardware ervoor geschikt is (oftewel voor current gen hardware) en anders opengl, zonder dat devs voor 2 apis moeten ontwikkelen. dan kun je dus oudere games met minder optimalisaties op je nieuwe gpu spelen, maar draait het alsnog redelijk door de snellere hardware

nu moeten devs om dat te bereiken op zn minst voor dx11 of opengl en voor dx12 of vulkan ontwikkelen als ze zo'n lower level api willen gebruiken, anders hebben ze een heel beperkt publiek nu en draait de game over een paar jaar misschien niet meer op nieuwe hardware. daarmee is het dus praktisch alleen voor triple A weggelegd.

[Reactie gewijzigd door Origin64 op 24 juli 2024 16:29]

[SuperDre]

Maar de huidige OpenGL implementatie blijft gewoon aanwezig juist vanwege oudere software.
Het feit dat je nu nog steeds hele oude games op je nieuwste GPU kunt spelen zegt toch genoeg. af en toe heb je wat problemen, maar in de meeste gevallen werkt het gewoon.

[Origin64]

ja, dat komt omdat er al heel lang high level apis worden gebruikt. en het is ook een goede reden om aan te nemen dat games niet exclusief voor low level apis uit zullen komen. hiermee zijn de low level apis dus voorbehouden aan grote studios met diepe zakken. niet iedereen kan het zich veroorloven om voor meerdere verschillende apis te programmeren en optimaliseren. misschien zal het wel betaalbaar zijn als je een licentie neemt op een cryengine ofzo die het ondersteunt. maar die is dan ook duurder dan als hij alleen dx11 of opengl ondersteunde.

[Reactie gewijzigd door Origin64 op 24 juli 2024 16:29]

[shades]

kweenie hoor maar volgens mij is een api toch bedoelt om juist minder werk te hoeven hebben.... welke api dan ook

[Origin64]

een lower level api is inderdaad nog steeds minder werk dan direct de drivers voor iedere gpu aanspreken, maar het is meer werk dan een higher level api als directx of opengl. daartegenover staat dus snelheidswinst.

[SG]

Hogere abstracctie houd in minder werk dus snellere tine to market , maar uiteraard ten koste van peformance. Voor kleine titels die hardware niet tot uiterste drijven voldoet DX11. Voor nog kleinere producties de meeste indie games is zelfs C++ niet nodig en gaat men zelfs voor higher level talen.
Vaak zelfs gebruiken ze dan de voor indies populaire engines of frameworks.
Zoals Unify3D.

Daar tegen over staan er de grotere productie die de hardware willen pushen en DX11 een belemmering is geworden. Het is ook vanuit die meer top developers dat er vraag is naar low level API. Ook heb in team ook een 3D engine guru nodig die naast meer werk ook de complexiteit ervan er goed mee vooruit kan.

[Origin64]

pas heb ik for the king gespeeld, dat hele spel is volgens mij in ms visual c++ gemaakt, er zat geen directx redist bij

[Nox]

Zou er al bekend zijn wat de winst is ten opzichte van Dx11? En wordt de api dan onderdeel van Dx12 of gaat de api geheel Dx12 vervangen? Dat laatste zou erg fraai zijn, dan zou, indien de api op Linux goed werkt, gamen op Linux ook mogelijk maken...

[Evo94]

De winst hangt natuurlijk af van een hoop factoren: CPU/GPU architectuur, CPU core count, de kwaliteit van de implementatie van de software ontwikkelaars etc.

Als voorbeeld, de manier waarop AMD & Nvidia kaarten GPU taken afhandelen verschilt zo dat Nvidia kaarten in beginsel meer baat hebben met DX11 (en de winst met DX12 minder is), terwijl vergelijkbare AMD kaarten minder presteren op DX11, maar beter zouden scalen met DX12.

Ingaande op je andere punt, de beste oplossing is om Vulkan te implementeren naast DX12 (en andere API's als DX11 en OpenGL voor legacy systemen). De voornaamste reden is dat sommige systemen zoals de Xbox One alleen werken met DX11/12, Linux alleen OGL/VK en noem maar op.

edit: Correcties en verduidelijkingen na inzicht op .oisyn's reactie, dank!

[Reactie gewijzigd door Evo94 op 24 juli 2024 16:29]

[.oisyn]

Nvidia kaarten het meesten baat hebben met DX11

Dat is niet helemaal waar. Wat vooral zo is, is dat NV het gigantisch veel beter doet in DX11, waardoor het verschil met DX12 relatief klein is, en je als developer verdomd goed in je schoenen moet staan om NV's DX11 driver te outperformen.

De voornaamste reden is dat sommige systemen zoals de Xbox One alleen werken met DX12

Geen idee of je het zo bedoelt, maar ter volledigheid: de Xbox One doet ook DX11. Het is bovendien een superset ervan, er zijn een hoop low-level functies die voorbij gaan aan de hardwareabstracties zoals de PC die kent (en logisch natuurlijk), en daardoor efficienter zijn.

[SG]

Het hangt ook sterk van soort game af. Niet alle game formulas en concepten hebben hoge mate aan drawcalls nodig. Ook voor triple A games. Zoals een corridor shooter.
Drawcalls zijn ook niet gelijk. Een paar zware of vele hele lichte.

Voorbeeld is die beruchte DX12 RTS met zijn vele units. Een oude voorganger TotalAnilation had je max van 200 units. Als je dat opschroeft naar paar 1000. Uierteraard met de effecten erbij kom je een heel eind kwa drawcalls. En dan maakt multithreade opbouwen van commandbuffers nogal wat uit.

Zelf van plan om simple Data orriented entity component system te testen. Op heel sterk versimpelde styl als Battle Isle 2, maar dan met space theme als home world.
Een drawcall is point sprite en of kleine icoontjes. Waarbij deze kwa gfx bewegen en status veranderen en verdwijnen. Dus gfx heel licht. En dan opschalen fleets armada en drone frigates carriers.

Dus heel veel units in the running. Veel lichte drawcalls.

En daarmee er zijn dus heel veel games die dus amper schalen op deze API omdat die geen last hebben van de CPU bottleneck omdat ze genoeg hebben aan rond 1K drawcalles. En niet 15 voud.
Daarbij kunnen veel games GPU bound zijn omdat die 1K aan drawcalls de GPU zwaar stressen.

[hackerhater]

Eve Online is ook een mooi voorbeeld. Dat gaat hard met 800+ spelers in active combat in een systeem. Daarbij moet je dus denken aan 800+ schepen + wapensvuur + effecten + drones, etc

Dan krijgt je systeem zelfs op "potato-mode" het zwaar. Ik zou Vulkan in dit spel enorm toejuigen.

[SuperDre]

De cryengine ondersteund dan gewoon beide API's, immers zal Vulkan niet beschikbaar komen op bv de xbox.

[SSDtje]

Vulkan will work on far more systems, including:

Windows, Mac, Linux, steam os (critically including the upcoming steam machines), android, ios and potentially the ps4. It would even be possible to run in Xbox one given it's a Windows 10 based device and Vulcan is fully Windows compliant (it's ms trying to control the eco system that prevents it). Finally PA is a fully opengl based game, and porting opengl 3 to vulkan is way less work than opengl to direct X.

Als ik het onderstreepte stukjes uit de teks hierboven dan weer lees, zet je dat toch wel even aan het denken, als dit in de toekomst nou nog wel of niet gaat gebeuren.
Aangezien de heer/dame die dat stukje er heeft neergezet, daarmee wel een punt heeft.
Aangezien de Xbox One inderdaad Windows 10 based is.
Hmm....
Bron

Edit: Typo's

[Reactie gewijzigd door SSDtje op 24 juli 2024 16:29]

[SuperDre]

xbox one is windows 10 based, maar zoals er dus staat wel controlled, en lang niet alles zal draaien op de xbox one. MS zal liever gewoon hebben dat er maar 1 API is zodat ze die zo goed mogelijk kunnen optimaliseren voor de hardware van de xbox. En voor de meeste developers maakt het toch niet uit, die gebruiken toch een game-engine als Unity, UE4, CryEngine of Frostbyte, en de makers van die engines zijn degene die zich druk maken over de verschillende API's..

[SSDtje]

"MS zal liever gewoon hebben dat er maar 1 API is zodat ze die zo goed mogelijk kunnen optimaliseren voor de hardware van de xbox"

Treu, en geef ze ook eens ongelijk.
Mochten ze dit op een later moment toch nog willen, dan kan dat waarschijnlijk terzijde tijd ook nog wel weer toegevoegd worden.

"En voor de meeste developers maakt het toch niet uit, die gebruiken toch een game-engine als Unity, UE4, CryEngine of Frostbyte, en de makers van die engines zijn degene die zich druk maken over de verschillende API's"

En ook hier geldt, geef ze eens ongelijk, die zien hun marktaandeel zo alleen maar meer inslinken namelijk.
En dat vinden ze natuurlijk niet leuk.

Edit: Nog even iets aan mijn reactie toevoegd.

[Reactie gewijzigd door SSDtje op 24 juli 2024 16:29]

[SG]

Game engines en of frameworks zijn API belangrijk voor ondersteunvan vele platform voor dev clienten. Die bepalen welke API benut zal worden. En hie crossplatform ze willen gaan.
De meest populaire licenseerbare engine maken de vele API abstracter voor devs om makelijker en dus productiever crossplatform te ondersteunen.

Een inhouse engine moeten de devs elke API die nodig is voor hun crossplatform zelf implementeren zo ook game editing tools chain. Wat een enorme last is. Kost veel tijd en je benader er niet direct mee de bestaande Engine voor je eerste productie , die iteratie evolutie hebben van 10 jaar.
Bij de tweede of derde productie wordt dat niveau behaald.

[Raventhorn]

Zover ik weet zijn DX12 en Vulkan elkaars tegenhangers, net als DX11 (en eerder) en OpenGL.
DX12 zal nog steeds alleen onder Windows werken, Vulkan kan cross-platform gebruikt worden. (Net als DirectX 11 en eerder alleen native onder Windows werken (WINE kan een hoop), en OpenGL cross-platform)

Microsoft blijft nog steeds doorgaan met het ontwikkelen van haar DirectX API, de Khronos Group met het ontwikkelen van Vulkan.
Er is dus, zoals ik je post in ieder geval interpreteer, geen sprake van dat Vulkan deel wordt van de DX12 API, of deze zou vervangen. Het zijn eerder concurrenten

Het is uiteindelijk aan de game bouwers om te kiezen welke API's ze al dan niet implementeren...

[glashio]

http://vulkan.gpuinfo.org/ Als steeds meer games ontwikkeld worden op Vulcan. Dan is switchen naar SteamOS / ChromeOS (2.0) of MacOS stuk eenvoudiger voor de gamers (geen reden meer om windows te draaien)

[SG]

De grootste reden voor platformen te kiezen zijn exclusives van grote titels en IP.
De console war maakt daar de firma's gretig gebruik van.
Windows geniet ivm de grote link van toolchain met xbox en gezien het de grootste PC markt is met groot verschil de marktleider is kwa exclusives tov Mac & Linux.
Als gamer voor consoles gaat het daar sterk om de exclusives welke je kiest. Fan zijn kleiner hardcore groep dat bij merk blijft hangen.
Crossplatform heb je te maken met enkele platformen waar vulkan niks hebt. Consoles en Mac.
Dus je moet sowieso naast vulkan xbox api de sony API nintendo en Metal.

Met vulkan heb Linux native op windows alternatief voor DX11 en W10 ook alternatef voor DX12.
Indie die kleinere markt bedienen kunnen Vulkan main API maken door exclusief voor Linux main en windows second te ontwikkelen tot exlusive voor linux.

Grotere productie hebben die luxe niet met hun multimilioenen kapitaal wat weer terug verdiend moet worden met flinke marge dus zijn grote platformen nodig met aantekkelijke markt voor volumesales.
En dan zie je dat afzet Markt >> API. Dat is engine implementatie detail voor sub team voor iedere port die in productie planning voorkomt.

Consoles hebben dus ook last van dat elke nextgen bij markt van 0 begint. En dus zwaar platform gepushed moet worden. De fans heb je. Maar dat is niet genoeg.
Linux is nog te klein. Dus ook exclusives nodig.
Als Valve ballen had dan kunnen paar IP exclusive releasen op SteamOS dan heb je de Linux fans. En daarbij de fans van elke IP waar exclusieve op steamOS titel Gereleased van is.
Maar ja als publisher met core bussness van digital releasen van games. Is crossplatform interresanter en exclusive zullen voor dat pushen effect heeft beperktere omzet voor games reduceren. Consoles werken met royalties per game sale.
De PC markt niet , dus exclusive pushen maakt dat mogelijk commercieel gezien minder aantrekkelijk.

[Reactie gewijzigd door SG op 24 juli 2024 16:29]

[Riyyi]

macOS support alleen geen Vulkan en staat ook niet op de planning, zij hebben Metal, helaas.
MoltenVK is een translator van Vulkan naar Metal, maar dat is natuurlijk niet even snel als native support, en we weten niet of developers dit gaan gebruiken. https://moltengl.com/moltenvk/

[SG]

Grotere producties werken met console developerkits.
Dus dan heb je te maken met developerkits voor Xbox en de Xbox specifieke API DX X.
Gezien dat met Visual studio defacto standaard in de industrie de PC DX toolchain samen met Xbox toolchains al sterk intergraal is.

Is Xbox family en PC DX11 en DX12 al beschikbaar.
Daarbij is Xbox de main samen met de PS toolchain.
Als PC is vaak secondaire target.

De reden dat bij beperkingen in produtie kwa port.
Er vaak alleen naast Xbox windows erbij gepakt wordt.

PS erbij voor kleine team ondanks dat platform commercieel belangrijker is als main target. Is PC erbij vaak wel haalbaar als productie scope klein is. Omdat kleinere last is voor kleine team

[SSDtje]

"Bij multi-gpu in DX12 kan de software de rekenkracht combineren van verschillende gpu's, zonder dat deze in een crossfire- of sli-opstelling zijn geplaatst"

Houd dit in dat er tussen de twee, of meer GPU's in een systeem dus geen bridge meer geplaatst hoeft te worden, wanneer dit toegepast gaat worden / wanneer het zover is.

[Reactie gewijzigd door SSDtje op 24 juli 2024 16:29]

[Sebazzz]

Dit lijkt mij interessant voor APU's. Stel dat je bijvoorbeeld een AMD APU hebt en daar bovenop een dedicated grafische kaart. Het zou geweldig zijn als je op die manier je hardware tot het maximale kan benutten.

[SSDtje]

Dat is dan ook één van de dingen waar ik aan zat te denken, al beschik ik zelf niet over een APU.
Maar voor de mensen die hier wel over beschikken, zou dat op deze manier toch een aardige boost aan je gfx moeten kunnen geven.

[Laurens-R]

Yep dat houd het in. Volgens de documentatie, hoeven de kaarten ook niet van eenzelfde klasse te zijn. Je GTX1080Ti en je integrated Intel Graphics chip kunnen bijvoorbeeld ook samenwerken in dit scenario. Of het uiteindelijk ook goed gaat werken moet nog blijken; voor zover ik weet zijn er nog geen games/benchmarks die hier uitgebreid gebruik van maken.

[SG]

PCI-e bus is de bridge het is dus wel belangrijk wat voor bandbreedje je beschikbaar hebt.

Er zijn blijkbaar veel mobo met PCIe lanes beperking in aantal maar ook type.

Je kan op iGPU postprocsessing doen.
Maar daarbij krijg je dus ook te maken ACE copy task die gaat over de PCIebus.
Als 4 pcie 2.0 via chipset. Of 16PCIe 3.0 direct aan cpu .
Dat is dus een aanzienlijk verschil.
Daarnaast igpu op cpu gebruiken het langzamere systeem geheugen.

Igpu gebruiken voor compute task dat niet verder op gpu voor andere taken gebruikt wordt. Maar de CPU mee verder gaat kan gebruiken van shared memory tussen cpu & igpu. Houd in geen copy task nodig.

[Laloeka]

Houd dit in dat er tussen de twee, of meer GPU's in een systeem dus geen bridge meer geplaatst hoeft te worden, wanneer dit toegepast gaat worden / wanneer het zover is.

Ik vermoed dat dit een vraag is. Het antwoord is in ieder geval "ja". De kaarten zullen met elkaar communiceren via de PCI bus.

[SuperDre]

Juist, en daarom zul je waarschijnlijk dus op minder kaarten de hardware voor crossbridge/sli gaan zien zitten, dat scheelt de fabrikant weer extra complexiteit.

[D0gtag]

In hoeverre verschilt dit van de star citizen implementatie, zij gebruiken de crytek engine fork lumberyard maar zouden zelf vulkan gaan implementeren. Jammer dat Vulkan nog geen multi gpu ondersteunt.

[dakka]

ik denk dat lumberyard door amazon word onderhouden, daarbovenop dat CIG de engine zover getweakt heeft dat ze volgens mij helemaal niks vanuit crytek meer pakken want het is uit zichzelf weer een half nieuwe engine, de star engine

[SuperDre]

Het feit dat ze nog niet zo heel lang geleden overgestapt zijn van hun eigen onderhouden engine gebaseerd op de cryengine 3 naar amazons lumberjack, zegt al wel dat dus hun eigen aanpassingen niet zo extreem meer zijn.

[Vale vista]

Waarom nu weer dat laatste stukje over DX12 multi adapter mode? Dat staat volledig los van de rest van het artikel????

[SG]

CryEngine is ontopic en zijn dus twee update in de pipeline Vulkan en multi adapter.

[wiLLius]

Als games goed de Vulkan API geïmplementeerd hebben, loopt het als een trein. Waardoor goede/equivalente prestaties, met mindere hardware mogelijk is, tov van andere APIs.

Vulkan is de toekomst. Vooral omdat het niet gebonden is aan 1 OS. Zoals DX12.

[SG]

Nou nee. De toekomst is wat productie beste support voor crossplatform.
Consoles hebben hun eigen devkits en toolchains, waar je dus aan
Xbox met windows DX-X DX11 en DX12 en buiten de MSVS set akternatieven OpenGL en vervanger Vulkan.
Sony devkit en toolchains
Nintendo devkit toolchains.
MacOS Metal toolchain.
Linux openGL en vervanger Vulkan.

Vulkan deeld opengl op linux.
Is alternatief op windows
De rest sony nintendo mac is niet vulkan.

Dus Vulkan is niet de toekomst.
Het is gewoon 1 van de API die je nodig hebt om volledig crossplatform te zijn.

[Triaxlium]

"Ondersteuning Vulkan-api komt na uitstel eind juli beschkbaar in CryEngine 5.4" Denk dat het beschikbaar moet zijn

[Whis!]

Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 44

[Triaxlium]

Noted