Khronos brengt Vulkan 1.0-api uit

De Khronos Group heeft versie 1.0 van de Vulkan-api vrijgegeven. Tegelijkertijd hebben AMD en Nvidia bètadrivers met Vulkan-ondersteuning uitgebracht. De api is de opvolger van OpenGL en gaat de concurrentie aan met Microsofts DirectX 12 en Metal van Apple.

Naast het bekendmaken van de definitieve specificaties van Vulkan 1.0 heeft Khronos ook een sdk voor ontwikkelaars uitgebracht. Alle documentatie omtrent Vulkan is beschikbaar op GitHub. Ontwikkelaars kunnen per direct aan de slag met de nieuwe api, maar ook gebruikers kunnen Vulkan uitproberen, want zowel AMD als Nvidia hebben dinsdag bètadrivers met Vulkan-ondersteuning uitgebracht en op Steam is inmiddels de eerste game met voorlopige Vulkan-ondersteuning verschenen. Het gaat om de nieuwste publieke bèta van The Talos Principe.

Vulkan is een low level-api voor het aansturen van de gpu. De api is grotendeels afgeleid van AMD's Mantle en geeft direct toegang tot diepere lagen van grafische hardware, zodat de overhead verminderd wordt. Andere voordelen van de api zijn dat deze royalty-free is en dat het een open standaard betreft, die gebruikt kan worden op alle platforms, mits deze daar ondersteuning voor bieden. Momenteel zijn dat Windows, Linux en Android. Apple focust sinds 2014 op zijn eigen Metal-api en lijkt daarom Vulkan niet meer te willen ondersteunen in iOS en OS X.

Nu Vulkan 1.0 is uitgebracht is het de verwachting dat binnenkort meer games volgen met ondersteuning voor de nieuwe api. Onder andere Unity, Epic, Valve en Dice hebben toegezegd Vulkan te gaan ondersteunen met hun game engines. In hoeverre dat een snelheidswinst oplevert ten opzichte van andere low level-api's zal nog moeten blijken.

De api was al beschikbaar als open bèta en stond aanvankelijk bekend onder de naam glNext. De Khronos Group is een consortium waarin tal van bedrijven zijn vertegenwoordigd. Diverse bedrijven steunen de groep of dragen zelf bij aan de ontwikkeling van de Vulkan-api. Dat zijn onder andere Google, Qualcomm en Imagination. Laatstgenoemde is de maker van de PowerVR-gpu's voor smartphone-socs.

Reacties (71)

[FricoRico]

Ik vind het jammer dat Apple hun eigen API (Metal) niet open-source heeft gemaakt. Een port naar Linux zou alleen maar gunstig uitpakken voor beide platformen om eens de echte concurrentie aan te gaan met Microsoft DirectX.

Metal is ansicht een goede toevoeging/verbetering ten opzichte van OpenGL, maar Apple kan niet de arrogantie permitteren waarbij ze denken dat developers tijd willen investeren in het integreren van hun eigen API.

Hoe je het wend of keert; Game developers krijgen vaak de schuld als het gaat om de performance issues, terwijl het hun taak is om een zooi mooi mogelijk, leuk mogelijk en vloeiend mogelijk spel te ontwikkelen. Tegenwoordig heb je al een leger aan developers nodig om al deze API's en SDK's te leren en gebruiken lijkt het wel. Een goede eenduidige standaard voor ieder platform zou ideaal zijn, maar de 'strijd' waarbij er alleen maar verliezers zijn, gaat maar door.

Ik hoop dan ook als Apple gebruiker dat ze toch de Vulkan API gaan ondersteunen. Anders zal de geringe hoeveelheid games alleen maar kleiner worden ben ik bang. Gelukkig tonen bekende game engine ontwikkelaars zoals Epic (Unreal Engine) en Unity 3D nog wel interesse in de Metal API's... Maar voor hoe lang nog?

[Overv]

Het is inderdaad jammer dat Apple voorlopig Vulkan niet officieel zal ondersteunen, maar er is wel een initiatief om Vulkan bovenop Metal te implementeren:

https://moltengl.com/metalvk/

[Pyrone89]

Waarom zou Apple het niet ondersteunen? Ze ondersteunen nu ook OpenGL wat volgens mij zelfs een onderdeel vormt van Metal. Zouden ze dan echt bewust een oudere versie blijven gebruiken (Vulkan is eigenlijk een andere naam voor wat anders OpenGL 5.0 was gaan heten) die dus ook impact heeft op hun eigen API puur en alleen om niet Vulkan te promoten?

Lijkt me nogal sterk. Apple bouwt immers ook gewoon al sinds jaren zowel Thunderbolt als USB3 in haar apparaten, dus als ze dit soort kwesties zo zouden spelen hadden we het daar ook moeten merken.

Zover is er zover ik weet nog geen bekendmaking of zelfs hint van Apple geweest dat ze dit niet gaan ondersteunen. En ze ondersteunen genoeg softwareplatformen van anderen zoals ook SMB (Microsoft), Linux (hun eigen Swift), de open bestandsformaten voor Agenda en Contacten, Exchange (Microsoft) etc.

[Reactie gewijzigd door Pyrone89 op 22 juli 2024 21:11]

[dmantione]

OpenGL 5 komt er nog "gewoon" hoor. Dat wordt gewoon verder ontwikkeld.

[Overv]

Je noemt een aantal dingen die niet helemaal waar zijn.

• Apple ondersteund OpenGL al jaren niet goed. De grafische kaarten in MacBooks kunnen zonder problemen OpenGL 4.5 aan met de NVIDIA drivers, maar Apple staat deze niet toe op OS X. Daardoor blijft OS X gelimiteerd tot OpenGL 4.1 en is de performance significant slechter dan wanneer je Windows met de NVIDIA driver draait op precies dezelfde hardware.
• Vulkan staat helemaal los van OpenGL. Het is goed mogelijk dat er alsnog een OpenGL 5.0 uit zal komen die niks met Vulkan te maken heeft.

Het is natuurlijk mogelijk dat Apple op een gegeven moment Vulkan alsnog officieel gaat ondersteunen, maar op dit moment is er geen enkele reden om dat aan te nemen.

[CrazyJoe]

Apple's implementatie van OpenGL loopt flink achter bij waar de standaard nu is. Apple heeft alleen een implementatie van OpenGL 4.1 (uit 2010) terwijl OpenGL ondertussen al op versie 4.5 zit.

Dit maakt het zeer moeilijk om de nieuwste OpenGL games te porten naar MacOSX zonder dat je het hele spel moet gaan porten naar Metal omdat versie 4.1 een groot aantal moderne features mist. (o.a. Compute Shaders).

Apple lijkt ook niet van plan om hun OpenGL implementatie nog verder te updaten.

Misschien dat ze Vulkan gaan ondersteunen, maar ik vrees dat ze gaan proberen om Metal te pushen. Dat bindt namelijk ontwikkelaars sterk aan MacOSX en iOS en dat is zeker in het belang van Apple.

[bogy]

apple snijdt zichzelf alleen maar in de vingers door het niet te ondersteunen...

we hebben nu een goed en heel up to date platform dat het beste uit de hardware haalt; ik neem aan dat de ps4 dit ook zal ondersteunen (is momenteel toch opengl en direct aangestuurd voor sommige games); omdat je met mantle/vulkan quasi geen verschil meer hebt tussen direct hardware programmeren (wat op pc's eigenlijk niet mogelijk is door al de verschillende hardware) en het gebruik van de API; zou dit een enorme boost kunnen betekenen voor multiplatform games.
het wordt nog gemakkelijker om een game te ontwikkelen voor bv windows en deze dan om te zetten naar linux, ps4, .
apple gaat nu nog meer games missen dan voorheen want als men de ganse markt kan bedienen met 1 platform gaat men niet speciaal voor 1 minder gebruikt platform nog eens speciaal alles herwerken. voor linux is dit een goed verhaal natuurlijk..

voor xbox games blijft natuurlijk gelden dat deze met directx worden ontwikkeld en op een windows-xboxmod kernel draaien; die games zijn enorm snel en gemakkelijk te fixen voor windows computers omdat die dezelfde api en dezelfde kernel draaien (alleen zonder xboxmod)

ik herinner me btw nog de voodoo dagen; waarin je in games kon kiezen tussen 3 api's; OpenGL (redelijk goed), DirectX (slecht in die tijd) en GLiDE (perfect, enkel voor voodoo)

[GekkePrutser]

Maar een extra conversie laag staat nogal haaks op het doel van Vulkan. Niettemin beter dan niks inderdaad.

[valvy]

Ik denk dat het alleen maar logisch is voor apple om hun metal api een open standaard te laten maken. Dan hebben ze een hele dikke vinger in de pap hoe de toekomst van graphics apis eruit gaan zien. Want momenteel maakt het onderdeel uit van een hoop productie software. En zijn er al stabiele drivers.

Apple heeft een geschiedenis om samen te werken met open standaarden. En hebben ze in het verleden ook opencl doorgegeven aan de kronos group.

[dion_b]

Metal open maken zou geweldig geweest zijn. Maar die boot is al gevaren nu Vulcan uitgebracht is. Doodzonde, en mogelijk grote strategische fout. Op de desktop is Apple een nichespeler die het kan permitteren om excentriek te zijn, maar in de mobile markt heeft Apple veel te verliezen als developers eerder voor een ander platform (of voor *alle* andere platforms) kiezen omdat ze voor iOS alles opnieuw moeten beginnen.

[Iblies]

Ik vind het jammer dat Apple hun eigen API (Metal) niet open-source heeft gemaakt. Een port naar Linux zou alleen maar gunstig uitpakken voor beide platformen om eens de echte concurrentie aan te gaan met Microsoft DirectX.

Metal is ansicht een goede toevoeging/verbetering ten opzichte van OpenGL, maar Apple kan niet de arrogantie permitteren waarbij ze denken dat developers tijd willen investeren in het integreren van hun eigen API.

Hoe je het wend of keert; Game developers krijgen vaak de schuld als het gaat om de performance issues, terwijl het hun taak is om een zooi mooi mogelijk, leuk mogelijk en vloeiend mogelijk spel te ontwikkelen..

Waarom open-source?

DirectX, opengl en vulcan zal het verschil niet maken in IOS. De gemene deler van de eerste drie is dat hoe sneller je kaart is, hoe beter de kwaliteit. Apple kan daar niet aan mee doen. De platforms zijn beperkt en bekend, iPad en iPhone, de mogelijkheden grotendeels ook, probeer daar vervolgens invulling aan te geven.
Je kunt een vergelijking maken met spelconsoles waarbij de hardware hetzelfde blijft maar gedurende de levensduur de kwaliteit van de games steeds beter worden omdat de grenzen worden opgezocht.

Het laatste wat je nodig hebt is dat hetzelfde game op een ander platform er beter uitziet. Precies hetzelfde iOS-game op vb een laptop.
Of dezelfde game in Android of Windows tablet/phone.

[dmantione]

Dat lijkt me een weinig toekomstvaste visie: Android heeft wel Vulkan. Uiteraard kan een Android-telefoon niet concurreren met een R9 Fury, maar mobiele hardware staat niet stil. Wat nu op een desktop moet draaien, draait in de toekomst op tablet en telefoon. Ook zonder dat zullen programmeurs het op prijs stellen als ze niet hun hele 3D-engine opnieuw hoeven te schrijven, maar enkel het grafisch detail omlaag hoeven te schroeven als ze naar mobiel porteren.

[Pyrone89]

Je bedoelt te zeggen dat dan duidelijk wordt dat Apple relatief under-specced hardware levert wat kan gezien hun goede en efficiënte software, maar dus niet als de software standaard is?

[Reactie gewijzigd door Pyrone89 op 22 juli 2024 21:11]

[MrFax]

Metal is meer bedoeld voor Apple's eigen producten, die zijn niet op high-end gaming gericht, Metal zal daarom dus ook nooit "de strijd" aangaan met Vulkan en DirectX in dit segment.

[Reactie gewijzigd door MrFax op 22 juli 2024 21:11]

[oef!]

Totdat Android (http://www.androidpolice....ming-versions-of-android/) iDevices in begint te halen. Al zie ik dat niet rap gebeuren.

[MacWolf]

Gelukkig tonen bekende game engine ontwikkelaars zoals Epic (Unreal Engine) en Unity 3D nog wel interesse in de Metal API's... Maar voor hoe lang nog?

Op mobile platformen wordt nog steeds het meest verdiend aan iOS gebruikers, dus zeker nog een lange tijd.

Ik verwacht dat software fabrikanten middleware maken die op iOS platformen gebruik maakt van Metal en op andere platformen van Vulkan. Tenminste als men iOS wilt ondersteunen en het spel moet multiplatform zijn.

Voor Mac OS X kan Vulkan waarschijnlijk wel gewoon ontwikkeld worden, gezien fabrikanten zelf drivers kunnen leveren en updaten zonder direct van Apple afhankelijk te zijn.

[Reactie gewijzigd door MacWolf op 22 juli 2024 21:11]

[Pyrone89]

Driver lopen bij Mac ook juist via Apple. Althans, ik heb nog nooit een driver hoeven downloaden, ze kwamen altijd via de App Store mee (soms zelfs zonder dat ik het zag).

Op dat vlak (in tegenstelling tot apps) is de Mac dus al wat meer de richting op van iOS

[Reactie gewijzigd door Pyrone89 op 22 juli 2024 21:11]

[rboerdijk]

Zelfde hier, ben zelf ook Apple gebruiker (de enige bij ons in de Firma) en toen mij werd gevraagd onze (openGL) game naar OSX te porten heb ik direct ja gezegd, hardstikke leuk.

Omdat we nu openGL hebben zal het volgende project ook op Windows, Linux en OSX lopen. Waarbij we vermoedelijk daarbij al parallel Vulcan gaan ondersteunen/bekijken... Het project daarna, tja... kans is aanwezig dat we dan OSX gaan droppen.
Uiteindelijk is OSX de "leuke bijkomstigheid" en niet ons hoofdplatform en als het met relatief weinig moeite aan de gang is te krijgen doen we het... Maar Metal (wat alleen op OSX werkt)...Het is heel onwaarschijnlijk dat we dat gaan doen, teveel moeite, te weinig opbrengsten.

[Xieoxer]

Apple heeft in de verleden al meerdere keren aangetoond dat Apple vrij snel is met het toevoegen van nieuwe technieken. Als het blijkt dat de techniek goed is uitgedacht, dan past het is de visie van Apple en zal het ondersteund worden.

[Dreamvoid]

Geringe hoeveelheid games? Er komen iets van 500 games per dag bij, en ik begreep altijd dat er meer iOS gamers zijn dan welk ander platform ook.

[SG]

Nou de schuld vraag ligt bij oude API minder bij de devs. Maar met de low level API komt die verantwoording juist meer bij de devs te liggen.
En nV grote driver team kan niet meer zo veel meer doen achter de driver. Zoals shader recompiles en game exe detecties en game profiles.
Wat uiteraard beter is voor driver dev team beperkte concurrent.

Gezien mantle als voorbeeld gebruikt is voor Vulkan en dit is bevestigd. Maar er ook in een artikel ergens is aangetoond dat early DX12 docs grotendeels kopieën waren van Mantle docs. Noem het maar de reguliere samen werking tussen AMD en MS.

De API lijken dus sterk op mekaar. En daarmee lijkt mij porten goed te doen.
Metal niet veel overgelezen, maar kan ook zijn dat de API nogal opgezet zoals al die andere lowlevel API.
Het is juist OpenGL die lastig is door wildgroei aan extenties en gebruik daarvan. En anders is dan DX11. Maar dat is implementie detail van module van API abstractie laag. Wat gewoon ingeplanned moet worden en team member of paar de expertise moeten hebben. En valt onder de port kosten producing en planning. Dat geen probleem is als je port goed wilt produceren. En goede publisher backing kwa funds.
API nukken is meer iets problemstisch voor cheap ports.

Meeste devs gebruiken licenceerbare engine. Die sowieso de belangrijkste API ondersteunen.
Met console support met onderandere xbox is DX API must en DX12 staat al dichter bij de xbox1 console lowlevel API .
Voor al die ander platformen openGL en Vulkan.
En Mac opengl en metal.
PS heeft ook zijn eigen opengl varianten.
Dus dat werk is grotendeels al gedaan door grote engine builders specialisten onder licenceerbare engine producties.
Kleine studios die de resources daar niet voor hebben. Zijn juist de licenseerbare game engine klanten en dus via unity of UE gebruik zullen maken van deze API door hun door engine ondersteunde target platform te kiezen.

[TheNephilim]

Ja het is echt erg, dat er door Apple toch weer een eigen implementatie bedacht moet worden. Terwijl die Vulkan API geheel open is en ze zich er prima bij aan kunnen sluiten. Wellicht ontwikkelt Apple gewoon hun 'Metal' om hun vendor-lockin nog verder uit te kunnen breiden.

[PrisonerOfPain]

Word on the street is dat de Metal api eigenlijk best problematisch is, het is destijd opgezet voor de iPhone en dat is te zien (geen HW tessellation support bv, en vrij 'tiler-oriented') blijkbaar heeft Apple zelf al genoeg problemen om Metal naar OS X om te zetten. Dus om daar nu een open standaard van te maken... liever niet

[Bjorn89]

Hopelijk is dit eindelijk de stap naar fatsoenlijke Multi-cpu/videokaart gebruik.

Betekend dit dat AMD ophoudt met Mantle?

[acemoo]

Ja.

http://support.amd.com/en...s/Radeon-Vulkan-Beta.aspx

What is Vulkan™?
As a complement to OpenGL, descended from AMD's Mantle, and forged by the industry, Vulkan™ is a powerful low-overhead graphics API that gives software developers deep control over the performance, efficiency, and capabilities of Radeon™ GPUs and multi-core CPUs.

[Overv]

Nee, er staat daar nergens in dat Mantle ophoudt met bestaan. In tegendeel, AMD heeft een bericht gepubliceerd waarin ze vertellen dat Mantle voortgezet wordt en gebruikt wordt als platform om innovaties te testen.

Mantle must take on new capabilities and evolve beyond mastery of the draw call. It will continue to serve AMD as a graphics innovation platform available to select partners with custom needs.

https://community.amd.com...-and-the-future-of-mantle

[freaq]

incorrect vulcan is gebouwd op een basis van Mantle (onderdelen)
http://www.extremetech.co...new-vulkan-api-vr-efforts

en AMD heeft al gezegd niet meer op mantle te gaan werken, (zowel voor henzelf als developers) en DX12 en Vulkan te gebruiken

van anandtech:
The situation then is that in discussing the performance results of the R9 Fury X with Mantle, AMD has confirmed that while they are not outright dropping Mantle support, they have ceased all further Mantle optimization. Of particular note, the Mantle driver has not been optimized at all for GCN 1.2, which includes not just R9 Fury X, but R9 285, R9 380, and the Carrizo APU as well. Mantle titles will probably still work on these products – and for the record we can’t get Civilization: Beyond Earth to play nicely with the R9 285 via Mantle – but performance is another matter. Mantle is essentially deprecated at this point, and while AMD isn’t going out of their way to break backwards compatibility they aren’t going to put resources into helping it either. The experiment that is Mantle has come to an end.

http://www.anandtech.com/...adeon-r9-fury-x-review/12

[Anoniem: 682068]

Voor zover ik weet is Mantle overgedragen aan Khronos om het mee te nemen in de Vulkan API, goede zaak lijkt me.

[SG]

Vulkan is Mantle fork. Vulkan bedankt ook AMD in bijzonder als donatie van mantle API aan hun. Aan het begin van 2015 GDC Vulkan item.

[rbr320]

De api is de opvolger van OpenGL

Dit is niet helemaal correct. OpenGL blijft gewoon bestaan en zal ook gewoon doorontwikkeld worden, aangezien dit veel gebruikt wordt in bijvoorbeeld de grafische industrie. Vulkan daarentegen is gebouwd om een betere API te bieden voor game ontwikkelaars, een schone lei zonder de overhead en legacy functionaliteit die OpenGL met zich mee draagt vanwege decennia lange ontwikkeling aan de API.

[ATS]

Een groot verschil is vooral dat Vulkan gebouwd is om multi-threaded te gebruiken. Dat was bij OpenGL nogal eens een bottleneck.

[rbr320]

Klopt. Pin me er niet op vast want ik ben geen expert, maar volgens mij zit multi-threading niet eens in de OpenGL 4 spec en is het er later (OpenGL 4.5?) in gehackt. Ik heb weinig developers er positief over gehoord in ieder geval.

[Pyrone89]

Aangezien de originele naam letterlijk was 'Next Generation OpenGL Initiative' lijkt mij wel degelijk dat dit de opvolger is.

Het zou een beetje hetzelfde zijn als Microsoft die Windows 8.1 blijft doorontwikkelen (geen security patches, maar echt doorontwikkelen) nu Windows 10 al 9 maanden uit is.

[dmantione]

Voor geavanceerde spelengines als Unreal of Unity is Vulkan de opvolger van OpenGL, daarover is geen twijfel. OpenGL wordt echter bijzonder breed ingezet, er zijn bizar veel toepassingen.

De reden waarom OpenGL naar verwachting ook op lange termijn blijft bestaan is dat de voordelen van Vulkan niet zeker voor iedere mogelijke toepassing relevant zijn, terwijl Vulkan aanzienlijk moeilijker is om voor te programmeren dan OpenGL. Voor een voorbeeld zou je kunnen denken aan een 2D-spel dat OpenGL voor de rendering gebruikt. De programmeurs daarvan zitten echt niet te wachten op het met hand beheren van het videogeheugen of het met de hand opbouwen van een renderingpijplijn voor 2D. Die willen gewoon op het scherm tekenen, en OpenGL geeft je die mogelijkheid.

[SG]

Ik heb ook meer idee dat vulkan opengl vervangt in de game industrie. En vulkan ook meer daar op gericht is.
Dus buiten de gamebranch blijft opengl relevant. Mogelijk meer in de pro markt. Maar ook in de mobile met hun SE versies.
Terwijl DX11 naast DX12 blijft gezien de industrie ook highlevel API vraag naar is. Naast performance hongerige dev naar low level API verlangen.

[rbr320]

Ik ging in mijn post inderdaad wat kort door de bocht. Vulkan mag wat 3D gaming betreft inderdaad gezien worden als de opvolger van OpenGL, maar OpenGL blijft in specifieke toepassingen gebruikt worden. Het zou me dan ook niet verbazen als er nog eens een OpenGL 5 spec komt.

Overigens is Vulkan ook toepasbaar op mobile, Google heeft al een team werken aan een volledige Vulkan driver implementatie voor in de volgende Android versie, maar ook daar zal OpenGL ES niet zomaar verdwijnen.

[mathijs727]

Eindelijk!
Ben bezig met mijn eigen render enginetje (mijn 5e poging om er geen rotzooi van te maken) en zat hier op te wachten.
OpenGL was een zooite dus ik hoop dat met vulkan een schone start gemaakt wordt.

Edit: zo te zien moet ik als AMD gebruiker nog even wachten. De Vulkan beta driver heeft geen DX support en kan je dus niet op je main pc gebruiken

[Reactie gewijzigd door mathijs727 op 22 juli 2024 21:11]

[Overv]

Hoewel de pagina met de Vulkan beta driver inderdaad aangeeft dat er geen DirectX ondersteuning in zit, lijkt het voor mij gewoon mogelijk te zijn om DirectX 11 en Vulkan applicaties met de beta driver te draaien. Ik kan ook zonder problemen tussen DirectX 11 en Vulkan wisselen met The Talos Principle. Ik heb voor de zekerheid ook eerst de normale driver helemaal verwijderd, dus het is geen overblijfsel daarvan.

[Overv]

Wat is DX support? Hier op Windows 10 werkt de AMD beta driver prima met de Vulkan demo's.

[mathijs727]

Direct x support. Betekend dat je de meeste games niet kan draaien op die driver.

Zie:
http://gpuopen.com/gaming-product/vulkan/

[Overv]

Ah, duidelijk.

[SG]

Het is ook duidelijk Vulkan doel om iig die OpenGL nukken te mijden.
Mij lijkt het dat Vulkan toch meer openGL vervangt.
Dan igv DX12 vs DX11.
Ook ondersteund DX12 een DX11 on12 methode voor geleidelijke overstap. Of een veel toegankelijke API mix voor die delen waar performance geen isue is.
Dat is handig als je high level font API van DX11 wilt gebruiken. DirectWrite etc.

[hcQd]

Ook de linuxdriver voor Intel is beschikbaar.

[MauriceEnschede]

Eindelijk. Ik kijk er al een tijd naar uit. Ik hoop nu dat developers het ook gaan gebruiken en meer cross platform games gaan maken.

[Stijn Weijters]

YES finally

[Riddos]

Stel ik wil een game ontwikkelen die niet heel high-end is. Ik ben dus niet geinteresseerd in thread en memory management. Is het voor mij dan nog wel interessant om met vulcan te gaan ontwikkelen? Betekend dan vulcan niet gewoon meer werk voor mij waar ik eigenlijk niet op zit te wachten. Ik heb zo iets van laat het dan maar lekker door de driver uitgezocht worden.

[duizel]

achja apple doet het toch altijd anders dan andere.
arrogante amerikanen zijn het.

[Pim0377]

Volgens mij staat er toch echt dat AMD EN nvidia bèta drivers hebben uitgebracht.

En ik betwijfel of we nu al op dit punt waren belandt als AMD niet zoveel werk van Mantel had gemaakt....dat heeft er voor gezorgd dat Microsoft ook eens van zijn reet afkwam so to speak en dat de opvolger van openGL er ook sneller kwam....gezien die is afgeleid van.....

[dmantione]

AMD heeft zojuist dit on-line gezet, toch een teken dat ze flink achter Vulkan staan:

https://www.youtube.com/watch?v=qZLzz3OOl3A#t=16

't komt wel goed met die drivers.

[Alfa1970]

Tja, AMD (of beter gezegd ATI dat ze hebben opgekocht) is mede oprichter van de Kronos group. Dus dan denk ik wel dat ze er enigszins achter zullen staan.

Voorlopig vind ik het eruitzien als het zoveelste me-too project.

[SG]

Vulkan is gebaseerd op Mantle als AMD heeft Mantle vrijblijvend die API aan hun gedoneerd. Mogelijk ook aan MS.

[Alfa1970]

Voor zover ik kan zien is Microsoft geen onderdeel van de Kronos group.
Dat hoeft ook niet echt, zij hebben zelf een prima functionerend product dat feitelijk hetzelfde doet.

Daarnaast is het helemaal niet slecht als er meer diversiteit door de verschillende API's, ieder voor zich zal goede zaken van de ander overnemen.

En het zijn zaken die m.i. prima naast elkaar kunnen bestaan.

Maar zoals ik al zei, ik vind het er een beetje uitzien als een "wij ook" terwijl er al redelijk veel andere oplossingen bestaan die hetzelfde doen.
Hoe standaard is deze zaak die een standaard heet te zijn als iedereen z'n eigen standaard heeft. Is het dan eigenlijk niet gewoon maar een van de vele "proprietary" oplossingen? Ondanks het open karakter?

[SG]

MS is imago en prestige geil zo als meeste tech bedrijven. En externe innovate tech reppen ze niet over.
Maar online zijn er bewijzen dat de early docs van DX12 mantle copien waren. Ondertussen is de naslag geupdate en DX12 ook aardig aangepast revisie 4 of meer.
En aangezien de API GPU en game industrie nouw samen werkt is dus het voor de hand liggend dat MS ook al vroeg toegang heeft tot mantle door de samenwerking in de game industrie tussen de drie branches.

[Alfa1970]

DirectX bestaat al een jaar of 20, Mantle is net uitgebracht.

Het is daarom m.i. aannemelijker dat AMD in Mantle onderdelen van DirectX heeft overgenomen net zo goed als dat ze onderdelen van OpenGL en andere technologieën hebben overgenomen.
Dat in een poging om zo de "best of both worlds" te bieden.

Dat delen van DirectX 12 daarom dus op Mantle lijken, lijkt mij niet zo vreemd.

Daarnaast is er voor veel zaken is echt geen radicaal andere API nodig.
Of het nu OpenGL, DirectX of Mantle is, bij alle 3 zal een 3D Vector 3 parameters hebben.

[SG]

Het meer aannemelijker dat DirectX veel legacy code on top of nog oudere legacy code gemaakt, uit een tijd dat Home PC nog uni core waren.

Dus een zeer brakke Multi thread DX11 implementatie on top of generaties legacy code heeft, die geen voordeel bracht dan SMP met dezelfde performance resultaat.
DX11 en ouder Driver heel veel uit handen nemen. Validatie checks, recompile van shader code doen en game profilering en herkenning. En nVidia dat deel juist Multi threaded gemaakt heeft.

Mantle is een API from scratch om alle legacy te droppen en hardware directer toegankelijker te maken met zeer dunne driver.
DirectX12 en Vulkan nemen dat concept over.

Je krijgt dan een van de grond af opgezette API met Multi core CPU in gedachte. En daar zit hem de winst in. Een juiste efficiëntie SMP implementatie die goed door schaalt.

Het is dus cruciaal om oude slechte Multi threaded implementaties te vervangen door de betere Multi threaded software enginering methodes.
Het is zeer moeilijk om bestaande software Multi threaded te maken omdat er knelpunten zijn die Multi threaded efficiëntie tegen werken. Zoals data of shared globals. Of functies die externe afhankelijk heden hebben. Dus resultaat niet gegarandeerd kan worden.
Mutexes en critical path methoden zijn leuk voor correct werkend SMP software. Maar het haald de parralellisatie onderuit. Maar de software blijft wel correct ipv crash of undefined behavior.

[Alfa1970]

ok, how to delete?

[Reactie gewijzigd door Alfa1970 op 22 juli 2024 21:11]

[Bjorn89]

Ik dacht dat AMD dit niet deed, vanwege de kosten die elke WHQL(standaard drivers, niet deze) met zich meebrengt. Vaak is er niks mis met de drivers, maar waarom 10x WHQL betalen voor kleine updates?

Geen idee in hoeverre dit nog klopt

AMD driver is sowieso niet volledig qua features.

(1) This product is based on a published Khronos specification but has not yet passed the Khronos Conformance Test Process. A fully conformant implementation of the Vulkan API will be included in a forthcoming Radeon Software release.

(2) This driver is intended as beta level support for use solely with Vulkan applications and as such some Radeon Software functionality has been removed. This is including and not limited to support for other Graphics APIs, Radeon Settings and other Radeon Software driver features.

[Reactie gewijzigd door Bjorn89 op 22 juli 2024 21:11]

[aval0ne]

Het heeft niets met WHQL te maken, iedere driver moet getest worden op conformiteit met de vulkan specs. Enkel Amd heeft drivers die niet daaraan voldoen, elke ander lid wel.

[dakka]

zonder AMD en mantle hadden we waarschijnlijk voorlopig nog geen DX 12 en vulkan

[Countess]

ach kijk, aval0n weer. Je moest goed zoeken om iets negatiefs te vinden om over AMD te zeggen of niet?

Ondertussen stelt de certificering weinig voor en is het nvidia die regelmatig crasht bij the talos principe, en niet AMD.

[Reactie gewijzigd door Countess op 22 juli 2024 21:11]

[Overv]

Ik heb wel op dit moment veel grafische glitches in The Talos Principle met AMD drivers in Vulkan modus.

[Reactie gewijzigd door Overv op 22 juli 2024 21:11]

[Sinester]

AMD en nVidia hebben allebei beta drivers beschikbaar, als je het over WHQL certified drivers hebt, heeft nog niemand dat

[Sinester]

https://developer.nvidia.com/vulkan-driver
Windows driver version 356.39 and Linux driver version 355.00.26 provide beta support for Vulkan.

Staat toch echt Beta bij, maar stuur maar een link om te laten zien dat jij gelijk hebt

in de zelfde post staat dat ze binnenkort met de officiële drivers komen

[Reactie gewijzigd door Sinester op 22 juli 2024 21:11]

[dmantione]

Dat Nvidia ze als beta beschouwt, hoeft toch op geen enkele manier uit te sluiten dat ze met vlag en wimpel door de Vulkan-comformiteitstest komen?

[SG]

Geld ook voor AMD. Beta kunnen ook al goed zijn. Of niet. Ook zo voor nvidia.

[dmantione]

Ze kunnen best bruikbaar zijn, maar er wordt juist van gemeld dat de drivers van AMD nog niet door de Vulkan-conformiteitstesten komen.

[Countess]

nee, ze zijn nog niet aangeboden voor validatie. Dat is iets anders.

[pwillemske]

Dat ze niet certified zijn wil niet zeggen dat ze slecht zijn. Heb een R9 290 gehad en geen enkel probleem met de drivers gehad. Nu over naar de 980Ti en ook hier geen enkel probleem met drivers. (tot nu toe)