Invoering

Als je met het probleem van lage FPS in DOOM wordt geconfronteerd en dit wilt oplossen, dan ben je hier aan het juiste adres.
Het magische ding Vulkan API verhoogt de FPS met gemiddeld 15-25 frames (afhankelijk van de configuratie van je computer), waardoor ongemakkelijke 20-30 FPS wordt omgezet in volledig speelbare 50-60.

AANDACHT! VOORDAT U DE IN DE HANDLEIDING BESCHREVEN STAPPEN UITVOERT, MOET U ERVOOR ZORGEN DAT UW COMPUTER TEN MINSTE AAN DE MINIMALE SYSTEEMVEREISTEN VOLDOET!

Wat is de Vulkan-API?

Wat voor soort beest is dit en hoe slaagt het erin de productiviteit zo aanzienlijk te verhogen?

Vulkan API is een grafische programmeerinterface die is ontworpen om 3D- en 2D-afbeeldingen op uw monitoren weer te geven. Simpel gezegd gebruikt deze onzin de bronnen van je computer om graphics in games te bouwen. OpenGL en DirectX komen uit hetzelfde verhaal.

Waarom geeft het zo'n hogere FPS? Ik kan je natuurlijk beginnen te vertellen over de superdupertechnologieën die erin worden gebruikt, maar omwille van de eenvoud zal ik gewoon zeggen dat het computerhardware veel efficiënter gebruikt dan zijn voorganger OpenGL.

Hoe schakel ik dit in?

Het is heel eenvoudig, laten we beginnen met de eerste stap:

Stap één:

Update de stuurprogramma's van uw videokaart naar laatst mogelijke versie. Als je niet weet hoe je dit moet doen, vraag het dan, want de instructies om ze bij te werken zijn behoorlijk lang, en de handleiding gaat daar helemaal niet over.

Stap twee:

Laten we DOOM zelf lanceren. Ga naar Instellingen>Geavanceerd en in het item " Grafische API" Selecteer "Vulkan API" in plaats van "OpenGL". Start het spel opnieuw.

Stap drie:

Laten we het spel ingaan en genieten van de verbeterde prestaties!

BELANGRIJK:

Verbeterde prestaties zijn sterk afhankelijk van de kenmerken van uw computer. In mijn configuratie bedroeg de toename maar liefst 30 FPS, voor sommigen kan dit veel minder zijn, terwijl anderen het verschil misschien helemaal niet voelen. En over het algemeen is het stom om minstens 30 FPS te verwachten van een broodrooster met Vulkan als deze bij minimale instellingen nauwelijks 10 produceert.

Het spel start niet nadat de Vulcan API is ingeschakeld. Wat moet ik doen?

Reden één:

U heeft de stuurprogramma's niet bijgewerkt of u hebt de verkeerde versie gedownload. Een nieuwere/stabiele versie uploaden.

Reden twee:

Uw videokaart heeft geen toegang tot de Vulkan API. Dit kan ook gebeuren, maar de kans is vrij klein. Als de videokaart past minimale eisen- het kan zeker werken met de Vulkan API. Als dat niet het geval is, zet het spel dan terug naar de standaardinstellingen en lijd aan OpenGL

Hoe kan ik het spel terugdraaien naar OpenGL als niets werkt?

Als de game weigert te starten na het overschakelen naar Vulkan, is hier een manier om terug te schakelen naar OpenGL:
Allereerst moet je naar de opslagmap gaan, deze bevindt zich op dit pad:
C:\Gebruikers\<имя_пользователя>\Opgeslagen games\id Software\DOOM\base
Vervolgens vinden we het bestand erin DOOMConfig.local en open het met kladblok.
Op zoek naar een parameter r_renderapi en de betekenis ervan veranderen 1 op 0 (1 - VulkanAPI, 0 - OpenGL)
Sla het bestand op en sluit het. Het spel zou nu moeten starten.

Hartelijk dank aan de gebruiker Arikuto voor het vinden van de instructies!

Vergeet niet de gids te beoordelen of uw kritiek/suggesties achter te laten!

Relatief recent is er een nieuwe Vulkan API uitgebracht - je zou kunnen zeggen de opvolger van OpenGL, hoewel Vulkan gebaseerd is op de Mantle API van AMD.
Natuurlijk stopte de ontwikkeling en ondersteuning van OpenGL niet en werd ook DirectX 12 uitgebracht. Helaas (of misschien gelukkig) weet ik niet wat er aan de hand is met DirectX 12 en waarom het alleen op Windows 10 werd geïnstalleerd. Maar platformonafhankelijke Vulkan interesseerde mij. Wat zijn de kenmerken van Vulkan en hoe je het correct kunt gebruiken, zal ik je in dit artikel proberen te vertellen.

Waar is Vulkan voor en waar kan het worden gebruikt? In games en applicaties die met graphics werken? Zeker! Berekenen zoals CUDA of OpenCL dat doet? Geen probleem. Hebben we hier echt een etalage of display voor nodig? Natuurlijk niet, u kunt kiezen waar u uw resultaat wilt uitzenden of helemaal niet. Maar eerst dingen eerst.

API-ontwerp en basisprincipes

Misschien moeten we met de eenvoudigste beginnen. Omdat de Vulkan API is ontwikkeld door de Khronous Group, lijkt de syntaxis behoorlijk op die van OpenGL. De gehele API heeft het vk-voorvoegsel. Functies (soms zelfs met zeer lange namen) zien er bijvoorbeeld zo uit: vkDoSomething(...), namen van structuren of handvatten: VkSomething, en alle constante expressies (macro's, macro-oproepen en opsommingselementen): VK_SOMETHING. Er is ook een speciaal type functie: opdrachten, waaraan het Cmd-voorvoegsel is toegevoegd: vkCmdJustDoIt(...).

Je kunt in Vulkan schrijven in zowel C als C++. Maar de tweede optie zorgt uiteraard voor meer gemak. Er zijn (en zullen worden gemaakt) poorten voor andere talen. Iemand heeft al een port naar Delphi gemaakt, iemand wil (waarom?) een port naar Python.

Dus hoe creëer je een rendercontext? Echt niet. Hij is niet hier. In plaats daarvan bedachten ze andere dingen met verschillende namen die zelfs op DirectX leken.

Aan de slag en basisconcepten

Vulkan scheidt twee concepten: het is apparaat (apparaat) En gastheer (gastheer). Het apparaat voert alle opdrachten uit die ernaar worden verzonden, en de host verzendt deze. In feite is onze applicatie de host - Vulkan heeft deze terminologie.

Om met Vulkan te kunnen werken hebben we handvatten nodig kopiëren (aanleg), en misschien zelfs meer dan één, evenals apparaat (apparaat), nogmaals, één is misschien niet altijd genoeg.

Vulkan kan eenvoudig dynamisch worden geladen. Als in de SDK (ontwikkeld door LunarG) de macro VK_NO_PROTOTYPES is gedeclareerd en de Vulkan-bibliotheek met uw eigen handen is geladen (niet met een linker, maar op bepaalde manieren in de code), dan heeft u allereerst de functie vkGetInstanceProcAddr nodig , waarmee u de adressen van de belangrijkste Vulkan-functies kunt achterhalen - functies die werken zonder een instantie, inclusief de functie om deze te maken, en functies die werken met de instantie, inclusief de functie van het vernietigen ervan en de functie van het maken van een apparaat . Nadat u een apparaat hebt gemaakt, kunt u via vkGetDeviceProcAddr functies verkrijgen die ermee werken (evenals de onderliggende handvatten).

Interessant feit: in Vulkan moet je altijd een bepaalde structuur met gegevens vullen om een ​​object te kunnen maken. En alles in Vulkan werkt ongeveer zo: van tevoren klaargemaakt - vaak en mee te gebruiken hoge prestaties. De exemplaarinformatie kan ook informatie bevatten over uw applicatie, engineversie, versie van de gebruikte API en andere informatie.

Lagen en extensies

In pure Vulkan zijn er geen sterke controles op de juistheid van binnenkomende gegevens. Er werd hem verteld iets te doen - hij zal het doen. Zelfs als dit leidt tot een applicatie-, driver- of videokaartfout. Dit werd gedaan omwille van de prestaties. U kunt echter zonder problemen verbinding maken verificatie lagen, en ook extensies indien nodig naar de instantie en/of het apparaat.

Lagen

Kortom, het doel van de lagen is om binnenkomende gegevens op fouten te controleren en de prestaties van Vulkan te monitoren. Ze werken heel eenvoudig: laten we zeggen dat we een functie aanroepen, en deze gaat naar de bovenste laag, opgegeven bij het eerder maken van het apparaat of de instantie. Hij controleert alles op juistheid en geeft vervolgens de oproep door aan de volgende. En zo zal het blijven totdat het de Vulkan-kern betreft. Natuurlijk kunt u uw eigen lagen maken. Steam heeft bijvoorbeeld de SteamOverlay-laag uitgebracht (hoewel ik niet weet wat deze eigenlijk doet). De lagen blijven echter stil, maar laten de applicatie niet crashen. Hoe weet je of alles correct is gedaan? Hiervoor bestaat een speciale extensie!

Extensies

Zoals de naam al doet vermoeden, breiden ze het werk van Vulkan uit extra functionaliteit. Eén extensie (foutopsporingsrapport) zal bijvoorbeeld fouten (en meer) uit alle lagen weergeven. Om dit te doen, moet u de benodigde terugbelfunctie opgeven, en wat u met de informatie die u in deze functie ontvangt, doet, is aan u om te beslissen. Houd er rekening mee dat dit een terugbelactie is en dat de vertraging u veel geld kan kosten, vooral als u alle ontvangen informatie rechtstreeks naar de console verzendt. Na het verwerken van het bericht kunt u opgeven of u de functieaanroep wel of niet verder wilt doorgeven (naar de volgende laag). Op deze manier kunt u voorkomen kritische fouten, maar probeer door te gaan met minder gevaarlijke fouten.
Er zijn ook andere extensies, waarvan ik er later in dit artikel enkele zal bespreken.

Apparaat

Vulkan scheidt de concepten van fysieke en logische apparaten. Fysiek apparaat Het kan uw videokaart zijn (en meer dan één) of een processor die grafische afbeeldingen ondersteunt. Logisch apparaat wordt gemaakt op basis van het fysieke: informatie over fysieke apparaten wordt verzameld, de benodigde wordt geselecteerd, een andere wordt voorbereid noodzakelijke informatie en het apparaat is gemaakt. Het kunnen er meerdere zijn logische apparaten gebaseerd op één fysiek, maar combineer voor verenigd werk fysieke apparaten(nog?) het is onmogelijk.

Dus wat voor soort informatie verzamelen we? Dit zijn uiteraard ondersteunde formaten, geheugen, mogelijkheden en natuurlijk wachtrijfamilies.

Wachtrijen en wachtrijfamilies

Het apparaat kan de volgende vier dingen wel of niet doen: afbeeldingen tekenen, verschillende berekeningen uitvoeren, gegevens kopiëren en werken met schaars geheugen (sparse geheugenbeheer). Deze mogelijkheden worden weergegeven als families van wachtrijen: elke familie ondersteunt bepaalde (misschien allemaal tegelijk) mogelijkheden. En als identieke families gescheiden zouden worden, zal Vulkan ze nog steeds als één familie presenteren, zodat we niet zo veel met de code hoeven te worstelen en de juiste familie moeten kiezen.

Nadat u de gewenste (of gewenste) gezinnen heeft geselecteerd, kunt u van hen wachtrijen opvragen. Wachtrijen zijn de plaats waar opdrachten voor het apparaat binnenkomen (het apparaat haalt ze vervolgens uit de wachtrijen en voert ze uit). Overigens zijn er niet veel wachtrijen en gezinnen. NVIDIA heeft doorgaans 1 familie met alle mogelijkheden voor 16 wachtrijen. Als u klaar bent met de selectie van gezinnen en het aantal wachtrijen, kunt u het apparaat aanmaken.

Commando's, hun uitvoering en synchronisatie

Alle opdrachten voor het apparaat worden in een speciale container geplaatst: de opdrachtbuffer. Die. Er is geen functie in Vulkan die het apparaat vertelt om onmiddellijk iets te doen en de controle terug te geven aan de applicatie wanneer de bewerking is voltooid. Er zijn alleen functies om de commandobuffer te vullen met bepaalde commando's (bijvoorbeeld iets tekenen of een afbeelding kopiëren). Pas nadat we de opdrachtbuffer op de host hebben geschreven, kunnen we deze naar de wachtrij sturen, waarvan al bekend is dat deze zich op het apparaat bevindt.

Er zijn twee typen opdrachtbuffer: primair en secundair. De primaire wordt rechtstreeks naar de wachtrij verzonden. De secundaire kan niet worden verzonden; deze wordt gestart in de primaire. Commando's worden geschreven in dezelfde volgorde waarin de functies zijn aangeroepen. Ze komen in dezelfde volgorde in de wachtrij. Maar ze kunnen bijna in een “chaotische” volgorde worden vervuld. Om volledige chaos in de applicatie te voorkomen, hebben Vulkan-ontwikkelaars synchronisatietools geleverd.

Nu het allerbelangrijkste: de gastheer Niet wacht op voltooiing van de uitvoering van opdrachten en opdrachtbuffers. Door ten minste totdat je het expliciet maakt. Nadat opdrachtbuffers naar de wachtrij zijn verzonden, keert de besturing onmiddellijk terug naar de applicatie.

Er zijn 4 synchronisatieprimitieven: hek, seinpaal, gebeurtenis en barrière.

Schutting De eenvoudigste synchronisatiemethode is dat de host kan wachten tot bepaalde dingen gebeuren. Bijvoorbeeld het voltooien van de uitvoering van een opdrachtbuffer. Maar het hek wordt zelden gebruikt.

Semafoor- synchronisatiemethode binnen het apparaat. Er is geen manier om de status ervan te bekijken of erop te wachten op de host, en je kunt er ook niet op wachten in de opdrachtbuffer, maar we kunnen wel specificeren welke semafoor een signaal moet geven wanneer de uitvoering van alle opdrachten in de buffer is voltooid, en welke semafoor moet worden gewacht voordat opdrachten in de buffer worden uitgevoerd. Alleen wacht niet de hele buffer, maar een bepaald stadium ervan.

Pijplijnfasen en uitvoeringsafhankelijkheden

Zoals reeds vermeld, zullen de opdrachten in de wachtrij niet noodzakelijkerwijs in de juiste volgorde worden uitgevoerd. Om preciezer te zijn: volgende opdrachten wachten niet tot de vorige zijn voltooid. Ze kunnen parallel worden uitgevoerd, of de uitvoering van de vorige opdracht kan veel later worden voltooid dan de daaropvolgende. En dat is heel normaal. Maar sommige ploegen afhankelijk uit de prestaties van anderen. Je kunt ze in twee oevers verdelen: "voor" en "na", en ook aangeven welke fasen van de "voor" kust noodzakelijkerwijs moeten worden uitgevoerd (dat wil zeggen dat de commando's mogelijk niet volledig of niet allemaal zijn voltooid) voordat de opgegeven fasen beginnen uit te voeren walopdrachten "na". Als u bijvoorbeeld een afbeelding tekent, kunt u pauzeren om bepaalde dingen te doen en vervolgens weer doorgaan met tekenen. Er kan ook sprake zijn van een keten van afhankelijkheden, maar laten we niet diep in de bossen van Siberië Vulkan duiken.

Evenementen- element van “fijnafstemming”. Je kunt zowel vanaf de host als vanaf het apparaat een signaal verzenden, maar je kunt ook op het apparaat en op de host wachten. De gebeurtenis bepaalt de afhankelijkheid van twee sets opdrachten (voor en na) in de opdrachtbuffer. En voor het evenement is er ook een speciaal pseudo-podium waar je op de gastheer kunt wachten.

Barrière kan opnieuw alleen worden gebruikt in het apparaat, of preciezer gezegd, in de opdrachtbuffer, waarbij de afhankelijkheden van de eerste en tweede reeks opdrachten worden aangegeven. U kunt ook geheugenbarrières specificeren, wat kan zijn drie soorten: mondiaal barrière, barrière buffer en barrière afbeeldingen. Ze staan ​​niet toe dat u per ongeluk de gegevens leest die erin zitten op dit moment worden geschreven en/of omgekeerd, afhankelijk van de opgegeven parameters.

Transportbanden

Hieronder staan ​​twee Vulkan-pijpleidingen:

Die. Vulkan heeft twee pijpleidingen: grafisch En computationeel. Met behulp van afbeeldingen kunnen we natuurlijk tekenen, en met berekeningen... kunnen we berekenen. Wat nog meer? De berekeningsresultaten kunnen vervolgens naar de grafische pijplijn worden verzonden. Zo kun je eenvoudig tijd besparen op bijvoorbeeld een deeltjessysteem.

U kunt de volgorde niet wijzigen of de fasen van de pijplijn zelf wijzigen. De uitzondering vormen programmeerbare fasen (shaders). U kunt ook verschillende soorten gegevens naar shaders sturen (en niet alleen) via descriptors.

U kunt een cache maken voor een pijplijn die (steeds opnieuw) kan worden gebruikt in andere pijplijnen en zelfs na het opnieuw opstarten van de applicatie.

Een pijplijn moet worden geconfigureerd en gekoppeld aan een opdrachtbuffer voordat deze pijplijnopdrachten kan gebruiken.

Erfenis van pijplijn

Omdat de pijplijn feitelijk alle informatie bevat over hoe met binnenkomende gegevens moet worden gewerkt, kan het veranderen van de pijplijn (en dit is informatie over shaders, descriptors, rasterisatie, enz.) kostbaar zijn in termen van tijd. Daarom boden de ontwikkelaars de mogelijkheid om de pijplijn te erven. Wanneer u een pijplijn wijzigt naar een onderliggend, bovenliggend of tussen onderliggend niveau, is er minder prestatieoverhead. Maar het is ook een gemak voor ontwikkelaars, zoals OOP.

Render-pass, grafische pijplijn en framebuffer

We krijgen dus de volgende matryoshka:

Om renderingopdrachten te kunnen gebruiken, hebt u een grafische pijplijn nodig. In de grafische pijplijn moet u dit opgeven render doorgeven (Geef door), dat informatie bevat over ondergangen (onderdoorgang), hun afhankelijkheden van elkaar en bijlagen (bijlage). Bijlage - informatie over de afbeelding die in framebuffers zal worden gebruikt. Er wordt speciaal voor een specifieke rendering-pass een framebuffer gemaakt. Om een ​​pass te starten, moet u zowel de pass zelf (en, indien nodig, een subpass) als de framebuffer specificeren. Na de start van de pas kunt u tekenen. Ook kunt u wisselen tussen subpassen. Zodra de trekking voltooid is, kunt u de pas voltooien.

Geheugenbeheer en bronnen

Geheugen in Vulkan wordt toegewezen door de host en alleen door de host (met uitzondering van swapchain). Als een afbeelding (of andere gegevens) in het apparaat moet worden geplaatst, wordt er geheugen toegewezen. Eerst wordt een hulpbron van een bepaalde grootte gemaakt, vervolgens worden de geheugenvereisten ervan opgevraagd, wordt er geheugen voor toegewezen, vervolgens wordt de hulpbron geassocieerd met een sectie van dit geheugen, en alleen dan kunnen de benodigde gegevens naar deze hulpbron worden gekopieerd. Er is ook geheugen dat rechtstreeks vanaf de host kan worden gewijzigd (host zichtbaar). lokaal geheugen apparaten (bijvoorbeeld videokaartgeheugen) en ook andere soorten geheugen, die op hun eigen manier de snelheid van toegang daartoe beïnvloeden.

In Vulkan kunt u ook uw eigen hostgeheugentoewijzing schrijven door Callback-functies in te stellen. Maar houd er rekening mee dat de geheugenvereisten niet alleen de grootte zijn, maar ook nivellering (uitlijning).

De bronnen zelf zijn er in twee soorten: buffers (buffers) En afbeeldingen (afbeeldingen). Beide zijn per doel gescheiden, maar als de buffer eenvoudigweg een verzameling verschillende gegevens is (vertex-, index- of constante buffer), dan heeft de afbeelding altijd zijn eigen formaat.

Advies aan degenen die op Vulkan schrijven

Wijs een geheugengebied toe waarin u meerdere bronnen tegelijk kunt plaatsen. Het aantal toewijzingen is beperkt en het kan zijn dat u niet genoeg heeft. Maar het aantal verenigingen is niet beperkt.

Schaduwen

Vulkan ondersteunt 6 soorten shaders: apicaal, controle van mozaïekpatroon, mozaïekanalyse, geometrisch, fragmentarisch(ook bekend als pixel) En computationeel. Je kunt ze op een leesbare SPIR-V schrijven en deze vervolgens samenvoegen tot bytecode, die we in een module in de applicatie zullen verzegelen, d.w.z. Laten we van deze code een shadermodule maken. Natuurlijk kunnen we het in de gebruikelijke GLSL schrijven en vervolgens converteren naar SPIR-V (we hebben al een vertaler). En natuurlijk kunt u uw eigen vertaler en zelfs assembler schrijven - de bronnen en specificaties worden in OpenSource geplaatst, niets weerhoudt u ervan een assembler te schrijven voor uw High Level SPIR-V. Of misschien heeft iemand het al geschreven.
De bytecode wordt vervolgens vertaald naar opdrachten die specifiek zijn voor elke videokaart, maar dit gebeurt veel sneller dan met onbewerkte GLSL-code. Soortgelijke praktijk geldt ook voor DirectX - HLSL wordt eerst geconverteerd naar bytecode, en deze bytecode kan worden opgeslagen en vervolgens worden gebruikt om shaders niet steeds opnieuw te compileren.

Ramen en displays

En dit artikel eindigt met een verhaal over WSI (Window System Integration) en de schakelketen (swapchain). Om iets in een venster of op het scherm weer te geven zijn speciale extensies nodig.

Voor ramen wel basis uitbreiding vlak en uitbreiding van het vlak specifiek voor elk van de systemen (win32, xlib, xcb, android, mir, wayland). Het beeldscherm (dat wil zeggen FullScreen) vereist de beeldschermextensie, maar over het algemeen gebruiken beide de swapchain-extensie.

De schakelketen is niet verbonden met de grafische pijplijn, dus een eenvoudig Clear Screen werkt zonder dit allemaal te configureren. Het is heel eenvoudig. Er is een bepaalde presentatie-engine, die een wachtrij met afbeeldingen heeft. Eén afbeelding wordt op het scherm getoond, anderen wachten op hun beurt. Ook kunnen wij het aantal afbeeldingen opgeven. Er zijn ook verschillende modi waarmee u kunt wachten op het verticale synchronisatiesignaal.

De manier waarop het werkt is ongeveer als volgt: we vragen de index van een vrije afbeelding op, roepen een opdrachtbuffer aan die het resultaat van de Framebuffer naar deze afbeelding kopieert, en sturen een opdracht om de afbeelding naar de wachtrij te sturen. Het klinkt eenvoudig, maar gezien het feit dat synchronisatie vereist is, is alles iets ingewikkelder, aangezien het enige dat de host verwacht de index is van de afbeelding die spoedig zal beschikbaar zijn. De commandobuffer wacht op een semafoorsignaal, dat de beschikbaarheid van het beeld aangeeft, en stuurt vervolgens zelf een signaal door de semafoor dat de uitvoering van de buffer, en bijgevolg het kopiëren, is voltooid. En het beeld komt daadwerkelijk in de wachtrij bij het laatste seinpaalsignaal. Er zijn slechts twee semaforen: over de beschikbaarheid van de afbeelding voor kopiëren en over de beschikbaarheid van de afbeelding voor weergave (dat wil zeggen over de voltooiing van het kopiëren).

Ik heb trouwens geverifieerd dat dezelfde opdrachtbuffer inderdaad meerdere keren naar de wachtrij is gestuurd. Je kunt zelf bedenken wat dit betekent.

In dit artikel heb ik geprobeerd de belangrijkste onderdelen van de Vulkan API te bespreken, maar er komt nog veel niet aan bod en dat kun je zelf ontdekken. Ik wens je stabiele FPS en prettige codering.

In de ontwikkeling van 3D-applicaties, videogames en systemen virtuele realiteit komt nieuwe fase. Samen hebben de ontwikkelaars gemaakt belangrijke stap op weg naar code-unificatie en meer effectief gebruik hardwarebronnen. De Khronos Group, een consortium van meer dan honderd bedrijven, heeft officieel de eerste versie onthuld van een open, platformonafhankelijke API genaamd Vulkan (voorheen GLNext). Het biedt directe controle over de GPU en CPU, waardoor knelpunten worden geëlimineerd en de algehele prestaties worden verbeterd.

Op forums zie je vaak hetzelfde soort vragen over de vraag of processor X videokaart Y zal openen en welke configuratie met hetzelfde budget productiever zal zijn specifieke toepassingen. Het komt voor omdat moderne GPU's betere prestaties leveren dan CPU's van hetzelfde niveau en dezelfde generatie. In games en andere 3D-toepassingen zijn er momenten waarop de CPU dit nodig heeft zware belasting, en de huisarts is inactief. De processor berekent bijvoorbeeld de interactie tussen spelers en objecten, en de videokaart wacht op gegevens ervan om het volgende frame te tekenen. Als gevolg van een onevenwichtige belasting treden er vertragingen op en kan een dynamisch spel veranderen in een frame-voor-frame diavoorstelling, zelfs met een krachtige videokaart.

Deze problemen zijn typisch voor het pc-platform en zijn vrijwel onbekend voor bezitters van gameconsoles. Ontwikkelaars van consolegames kennen altijd de gedetailleerde specificaties van consoles en kunnen diepgaande code-optimalisatie uitvoeren, rekening houdend met hun kenmerken. Computers, laptops en tablets zijn niet alleen een dierentuin van verschillende configuraties, maar ook van fundamenteel verschillende architecturen. Bij het maken van games voor zo'n divers platform wordt de prioriteit de universaliteit van de code, wat een negatieve invloed heeft op de snelheid van de uitvoering ervan.

Ontwikkelaars besturingssystemen ze proberen het probleem van low-code-efficiëntie op verschillende manieren op te lossen toepassingen van derden. Microsoft begon lang geleden te zoeken naar manieren om grafisch computergebruik te optimaliseren, maar echte ondersteuning voor bewerkingen op laag niveau verscheen pas in DirectX 12. Deze API is slechts in één besturingssysteem beschikbaar: Windows 10. Appel positie bleek dichter bij die van gameconsolefabrikanten te liggen. Wanneer hetzelfde bedrijf mobiele processors en software produceert, is het veel gemakkelijker om gecoördineerd werk te realiseren. Apple heeft echter nog lang niet alle manieren uitgeput om de ontwikkeling van games en applicaties te optimaliseren. Verscheen in iOS 8 Metaal-API, ook gericht op het gebruik van operaties op laag niveau.

Rest grote bedrijven handelen het liefst samen en binnen open standaarden. Het Khronos Group-consortium, dat zestien jaar geleden verscheen, bracht meer dan honderd fabrikanten samen, waaronder bloedvrienden als AMD, Nvidia en Intel. In één keer kwam het consortium aan het licht open standaarden OpenGL, OpenCL, OpenCV en vele anderen.

Vergeleken met OpenGL geeft Vulkan ontwikkelaars de mogelijkheid om bewerkingen op laag niveau te gebruiken zonder de portabiliteit van code in gevaar te brengen. Gebruik Vulkan aan verschillende platforms het is mogelijk om bijna hetzelfde uitgebalanceerde algoritme te bereiken als met gespecialiseerd spelconsoles. Met deze API kunt u de hardwaremogelijkheden beter benutten discrete videokaarten en geïntegreerde grafische chips in 2D- en 3D-modi.

Net als DirectX 12 ondersteunt Vulkan directe toegang tot GPU-geheugen. Bovendien vermindert Vulkan de afhankelijkheid van de weergavesnelheid van de kwaliteit van stuurprogramma's. Door de code van shader-programma's te vertalen naar een tussenliggend binair formaat, kan de compilatie ervan al in de ontwikkelingsfase worden uitgevoerd, en niet tijdens de lancering van de 3D-applicatie.

Vulkan is sinds medio 2014 in ontwikkeling. Het was gebaseerd op grafische bibliotheken nog een API op laag niveau - AMD Mantle. AMD fungeerde ook als redacteur van de officiële specificaties. Daarnaast publiceerde de Khronos-groep een aantal tests die de voordelen van de nieuwe API demonstreerden. Ze zijn allemaal beschikbaar op de GitHub-portal.

“Vulkan heeft een enorm potentieel”, zegt Dean Sekulic, programmeur bij Croteam. – Om het in één zin te zeggen: de komst van Vulkan maakte een einde aan een al lang bestaande confrontatie tussen strijders om codeprestaties en draagbaarheid. Nu dragen we het Talos-principe over om het nieuwe ontwikkelingsconcept te bevestigen.”

Valve sponsort de creatie van de open LunarG SDK met API-ondersteuning Vulkaan. Echter, ondanks open specificaties, beschikbare ontwikkeltools, het vermogen diepgaande optimalisatie code en andere voordelen zal Vulkan enige tijd een zelden gebruikte API zijn. De meeste gamemakers zullen trouw blijven aan DirectX 11/12 en OpenGL. Het is veel gemakkelijker om te vergroten systeemvereisten of de kwaliteit van grafische afbeeldingen verminderen in plaats van nieuwe ontwikkelmethoden onder de knie te krijgen. In dit besef streeft het Khronos Group-consortium ernaar om Vulkan niet alleen in nieuwe besturingssystemen te ondersteunen grafische oplossingen, maar ook op verouderde systemen.

Vulkan wordt momenteel ondersteund in Windows-omgeving(vanaf versie zeven), Linux, SteamOS en Android. Samsung's Tizen OS-ondersteuning zal naar verwachting binnenkort worden toegevoegd. Bètaversies van stuurprogramma's met ondersteuning voor de Vulkan API zijn al uitgebracht door AMD en Nvidia. De volgende zijn Intel, Qualcomm, ARM en andere fabrikanten die deel uitmaken van het Khronos Group-consortium. Een demo van Vulkan op een ARM Mali grafische chip is te zien in de onderstaande video.

Momenteel kan Vulkan worden getest op videokaarten met grafische chips Nvidia GeForce GT 630 en hoger, AMD Radeon HD 7700 en hoger. De Vulkan API ondersteunt ook hybride AMD-processors Met grafische kern Radeon HD 8500 – 8900 en R2 – R9. Ingebouwde grafische kaart voor desktop en mobiele processoren Intel ondersteunt Vulkan sindsdien Kern familie vijfde generatie.

De volledige mogelijkheden van de nieuwe API zullen worden onthuld door veelbelovende graphics Nvidia-processors Pascal-serie en AMD met GCN-architectuur van de vierde generatie. Vermoedelijk worden de bijbehorende videokaarten meegeleverd GTX-serie 1xxx en Radeon Rx 400. Volgens onofficiële gegevens is de start van hun verkoop gepland voor het tweede kwartaal van 2016.

Vulkan is een nieuwe API voor het maken van 3D-applicaties. Het is ontwikkeld door de Khronos Group, die ook OpenGL ontwikkelt. Geweldige bijdrage aan API-creatie geïnvesteerd AMD-bedrijf. Hoewel er veel andere bedrijven aan werkten, bijvoorbeeld Microsoft, Apple, Google, Sony. Deze API wordt ondersteund door hardwaremakers als: NVidia, AMD, Intel, Qualcomm, Imagination Technologies, ARM.

Hoe Vulkan verschilt van OpenGL

Het Wikipedia-artikel belicht vier belangrijke verschillen:

1. Er bestaan ​​geen mondiale staten; alle staten zijn gebonden aan objecten.
2. Statussen zijn gebonden aan de opdrachtbuffer, niet aan de context zoals in OpenGL.
3. In OpenGL wordt geheugenverwerking en synchronisatie niet expliciet gedaan; de ontwikkelaar heeft de mogelijkheid om dit te controleren.
4. Gebrek aan foutcontrole in de driver om het werk te versnellen.

Gebaseerd op het feit dat de nieuwe API vandaag is verschenen en dat de Khronos Group deze in de loop van 18 maanden heeft ontwikkeld in nauw contact met 's werelds toonaangevende IT-bedrijven, kunnen we concluderen dat deze API beter geschikt zou moeten zijn voor moderne 3D-toepassingen.

Hieronder kun je zien hoe Vulkan werkt:

Zal Vulkan naar Mac OS X komen?

Zodra de Vulkan-specificatie is gepubliceerd, zoekt u naar stuurprogramma's voor moderne videokaarten is niet moeilijk. Maar dit is alleen voor Windows en Linux. Omdat Vulcan slechts een platformonafhankelijke API is die geen speciale ondersteuning van videokaarten vereist, kunt u deze gaan gebruiken door het stuurprogramma bij te werken (als uw videokaart natuurlijk op de lijst met ondersteunde kaarten staat).

Voor Mac OS X zijn de zaken veel ingewikkelder. Er is geen Vulkan-ondersteuning in El Capitan, ik zou graag willen wachten volgende versies Er is echter één ‘maar’. Apple heeft ondersteuning voor zijn API - Metal - toegevoegd aan El Capitan. Voorheen werd het alleen gebruikt voor iOS-apparaten. Op basis hiervan, en ook gezien het feit dat Apple gewend is alles te controleren wat hun apparaten betreft, kunnen we concluderen dat Vulkan mogelijk niet op Mac OS X verschijnt.

Wat is het volgende?

Naar mijn mening hangt wat Vulkan te wachten staat grotendeels af van hoe actief ontwikkelaars het gaan gebruiken en ondersteunen door fabrikanten van videokaarten. Als de ontwikkeling van OpenGL hier stopt, is er geen keuze meer voor nieuwe applicaties en zullen deze in Vulkan ontwikkeld moeten worden. Maar er zijn duizenden OpenGL-applicaties die niemand onmiddellijk in Vulkan zal herschrijven. Het probleem met Mac OS X is ook niet duidelijk, aangezien dit een veel voorkomend systeem is in de VS. Als er Metal voor Mac OS X, DirectX voor Windows en Vulkan voor Linux bestaat, dan zal Vulkan op geen enkele manier de ontwikkeling van platformonafhankelijke applicaties vergemakkelijken.