Sissejuhatus

Kui seisate silmitsi madala FPS-i probleemiga DOOM-is ja soovite selle parandada, siis olete jõudnud õigesse kohta.
Maagiline asi Vulkan API tõstab FPS-i keskmiselt 15-25 kaadri võrra (olenevalt sinu arvuti konfiguratsioonist), muutes ebamugavad 20-30 kaadrit sekundis täiesti mängitavaks 50-60.

TÄHELEPANU! ENNE JUHENDIS KIRJELDATUD SAMMUTE TEOSTAMIST PEATE VEENDAMA, ET TEIE ARVUTI VASTAB VÄHEMALT SÜSTEEMI MIINIMUMNÕUETELE!

Mis on Vulkan API?

Mis metsaline see on ja kuidas suudab ta tootlikkust nii oluliselt tõsta?

Vulkan API on graafiline programmeerimisliides, mis on loodud 3D- ja 2D-graafika kuvamiseks teie monitoridel. Lihtsamalt öeldes kasutab see jama teie arvuti ressursse mängude graafika ehitamiseks. OpenGL ja DirectX on pärit samast loost.

Miks see FPS-i nii palju suurendab? Võin muidugi hakata rääkima selles kasutatud super-duper tehnoloogiatest, kuid lihtsuse huvides ütlen lihtsalt, et see kasutab arvuti riistvara palju tõhusamalt kui tema eelkäija OpenGL.

Kuidas seda lubada?

See on väga lihtne, alustame esimese sammuga:

Esimene samm:

Värskendage oma videokaardi draiverid viimane võimalik versioon. Kui te ei tea, kuidas seda teha, küsige , sest nende värskendamise juhised on üsna pikad ja juhend ei puuduta seda.

Teine samm:

Käivitame DOOM-i ise. Avage Seaded> Täpsemalt ja üksuses " Graafika API" valige "OpenGL" asemel "Vulkan API". Taaskäivitage mäng.

Kolmas samm:

Lähme mängu ja naudime suurenenud jõudlust!

TÄHTIS:

Parem jõudlus sõltub suuresti teie arvuti omadustest. Minu konfiguratsioonis oli kasv koguni 30 kaadrit sekundis, mõne jaoks võib see olla palju väiksem, samas kui teised ei pruugi vahet üldse tunda. Ja üldiselt on rumal oodata Vulkaniga rösterilt vähemalt 30 kaadrit sekundis, kui see toodab minimaalsete seadistustega vaevalt 10 kaadrit sekundis.

Mäng ei käivitu pärast Vulcan API lubamist, mida peaksin tegema?

Põhjus üks:

Te ei värskendanud draivereid või laadisite alla vale versiooni. Uuema/stabiilse versiooni üleslaadimine.

Põhjus kaks:

Teie videokaart ei pääse juurde Vulkan API-le. See võib ka juhtuda, kuid tõenäosus on üsna väike. Kui videokaart sobib miinimumnõuded- see saab kindlasti töötada Vulkani API-ga. Kui ei, siis keerake mäng tagasi vaikeseadetele ja kannatage OpenGL-iga

Kuidas mängu tagasi OpenGL-i tagasi keerata, kui miski ei tööta?

Kui mäng keeldub pärast Vulkanile üleminekut käivitamast, saate OpenGL-ile tagasi lülituda järgmiselt.
Kõigepealt peate minema salvestuskausta, mis asub sellel teel:
C:\Kasutajad\<имя_пользователя>\Saved Games\id Software\DOOM\base
Järgmisena leiame sellest faili DOOMConfig.local ja avage see märkmikuga.
Otsitakse parameetrit r_renderapi ja muuta selle tähendust 1 peal 0 (1 – VulkanAPI, 0 – OpenGL)
Salvestage fail ja sulgege see. Mäng peaks nüüd käivituma.

Suur tänu kasutajale arikuto juhiste leidmise eest!

Ärge unustage juhendit hinnata või jätke oma kriitika/ettepanekud!

Suhteliselt hiljuti ilmus uus Vulkani API - võib öelda, et OpenGL-i järeltulija, kuigi Vulkan põhineb AMD Mantle API-l.
Loomulikult ei peatunud OpenGL-i arendus ja tugi ning välja tuli ka DirectX 12. Kahjuks (või võib-olla õnneks) ma ei tea, mis DirectX 12-ga toimub ja miks see ainult Windows 10-le installiti. Kuid platvormideülene Vulkan huvitas mind. Millised on Vulkani omadused ja kuidas seda õigesti kasutada, püüan teile selles artiklis rääkida.

Niisiis, milleks Vulkan on mõeldud ja kus seda kasutada saab? Mängudes ja rakendustes, mis töötavad graafikaga? Kindlasti! Arvutage nagu CUDA või OpenCL? Pole probleemi. Kas selleks on tõesti vaja akent või kuvarit? Muidugi mitte, saate valida, kuhu oma tulemust edastada või üldse mitte edastada. Aga kõigepealt asjad kõigepealt.

API disain ja põhitõed

Võib-olla peaksime alustama kõige lihtsamast. Kuna Vulkan API töötas välja Khronous Group, on süntaks üsna sarnane OpenGL-ile. Kogu API-l on vk-eesliide. Näiteks funktsioonid (mõnikord isegi väga pikkade nimedega) näevad välja sellised: vkDoSomething(...), struktuuride või käepidemete nimed: VkSomething ja kõik konstantsed avaldised (makrod, makrokutsed ja loenduselemendid): VK_SOMETHING. Samuti on olemas spetsiaalne funktsioonitüüp - käsud, millele lisatakse Cmd eesliide: vkCmdJustDoIt(...).

Vulkanis saab kirjutada nii C kui ka C++ keeles. Kuid teine ​​võimalus pakub loomulikult rohkem mugavust. Seal on (ja luuakse) pordid teistesse keeltesse. Keegi on juba Delfisse pordi teinud, keegi tahab (miks?) porti Pythonile.

Niisiis, kuidas luua renderduskonteksti? Pole võimalik. Teda pole siin. Selle asemel mõtlesid nad välja muid erinevate nimedega asju, mis meenutaksid isegi DirectX-i.

Alustamine ja põhikontseptsioonid

Vulkan eraldab kaks mõistet – see on seade (seade) Ja peremees (peremees). Seade täidab kõik talle saadetud käsud ja host saadab need. Tegelikult on meie rakendus host - Vulkanil on see terminoloogia.

Vulkaniga töötamiseks vajame selle jaoks käepidemeid kopeerida (näiteks), ja võib-olla isegi rohkem kui üks, samuti seade (seade), jällegi ei pruugi ühest alati piisata.

Vulkani saab hõlpsasti dünaamiliselt laadida. Kui SDK-s (väljatöötatud LunarG) deklareeriti makro VK_NO_PROTOTYPES ja Vulkani teek laaditi oma kätega (mitte linkeriga, vaid teatud vahenditega koodis), siis kõigepealt vajate funktsiooni vkGetInstanceProcAddr , mille abil saate teada peamiste Vulkani funktsioonide aadressid - need, mis töötavad ilma eksemplarita, sealhulgas selle loomise funktsioon, ja funktsioonid, mis töötavad koos eksemplariga, sealhulgas selle hävitamise funktsioon ja seadme loomise funktsioon . Pärast seadme loomist saate vkGetDeviceProcAddr kaudu hankida sellega töötavad funktsioonid (nagu ka selle alamkäepidemed).

Huvitav fakt: Vulkanis peate mis tahes objekti loomiseks alati täitma teatud struktuuri andmetega. Ja kõik Vulkanis töötab umbes nii: eelnevalt ette valmistatud - saab kasutada sageli ja koos suur jõudlus. Eksemplari teave võib sisaldada ka teavet teie rakenduse, mootori versiooni, kasutatud API versiooni ja muud teavet.

Kihid ja laiendused

Puhas Vulkanis ei kontrollita sissetulevate andmete õigsust tugevalt. Talle öeldi, et tehku midagi – ta teeb seda. Isegi kui see toob kaasa rakenduse, draiveri või videokaardi vea. Seda tehti esituse huvides. Siiski saate ilma probleemideta ühenduse luua kinnituskihid ja laiendused vajaduse korral eksemplari ja/või seadmesse.

Kihid

Põhimõtteliselt on kihtide eesmärk kontrollida sissetulevaid andmeid vigade suhtes ja jälgida Vulkani jõudlust. Need töötavad väga lihtsalt: oletame, et kutsume funktsiooni ja see läheb ülemisse kihti, mis on määratud seadme või eksemplari varem loomisel. Ta kontrollib kõike õigsust ja edastab seejärel kõne järgmisele. Ja nii on see seni, kuni asi jõuab Vulkani tuumani. Loomulikult saate luua oma kihte. Näiteks Steam andis välja SteamOverlay kihi (kuigi ma ei tea, mida see tegelikult teeb). Kuid kihid jäävad vaikima, kuid ei jookse rakendust kokku. Kuidas teada saada, kas kõik on õigesti tehtud? Selle jaoks on spetsiaalne laiendus!

Laiendused

Nagu nimigi ütleb, laiendavad nad Vulkani tööd lisafunktsioonid. Näiteks kuvab üks laiend (silumisaruanne) kõigi kihtide vead (ja palju muud). Selleks peate määrama vajaliku tagasihelistamisfunktsiooni ja mida selles funktsioonis saadud teabega edasi teha, on teie otsustada. Pange tähele, et tegemist on tagasihelistamisega ja viivitus võib teile kalliks maksma minna, eriti kui väljastate kogu saadud teabe otse konsooli. Peale kirja töötlemist saad määrata, kas edastada funktsioonikutse edasi (järgmisse kihti) või mitte – nii saad vältida kriitilised vead, kuid proovige jätkata tööd vähem ohtlike vigadega.
On ka teisi laiendusi, millest mõnest räägin hiljem selles artiklis.

Seade

Vulkan eraldab füüsikaliste ja loogiliste seadmete mõisted. Füüsiline seade See võib olla teie videokaart (ja rohkem kui üks) või graafikat toetav protsessor. Loogiline seade luuakse füüsilise põhjal: kogutakse infot füüsiliste seadmete kohta, valitakse välja vajalik, valmistatakse ette teine vajalikku teavet ja seade on loodud. Neid võib olla mitu loogilised seadmed põhineb ühel füüsilisel, kuid kombineerida ühtne töö füüsilised seadmed(veel?) see on võimatu.

Millist teavet me siis kogume? Need on loomulikult toetatud vormingud, mälu, võimalused ja loomulikult järjekorrapered.

Järjekorrad ja järjekorrapered

Seade võib (või ei pruugi) teha järgmist 4 asja: joonistada graafikat, teha erinevaid arvutusi, kopeerida andmeid ja töötada vähese mäluga (hõre mälu haldamine). Need võimalused on kujutatud järjekordade peredena: iga perekond toetab teatud (võib-olla kõiki korraga) võimalusi. Ja kui identsed pered lahutati, siis Vulkan esitleb neid ikkagi ühe perekonnana, et me ei peaks koodiga nii palju rabelema ja õiget perekonda valima.

Kui olete soovitud (või soovitud) pered välja valinud, saate neilt järjekordi hankida. Järjekorrad on koht, kuhu saabuvad seadme käsud (siis seade võtab need järjekordadest ja täidab). Muide, järjekordi ja peresid väga palju ei ole. NVIDIA-l on tavaliselt 1 perekond, millel on kõik võimalused 16 järjekorra jaoks. Kui olete perede valiku ja järjekordade arvuga lõpetanud, saate seadme luua.

Käsud, nende täitmine ja sünkroonimine

Kõik seadme käsud paigutatakse spetsiaalsesse konteinerisse - käsupuhvrisse. Need. Vulkanis pole ühtegi funktsiooni, mis käsiks seadmel midagi kohe teha ja pärast toimingu lõppemist juhtimine rakendusele tagastada. Funktsioonid on ainult käsupuhvri täitmiseks teatud käskudega (näiteks joonista midagi või kopeeri pilt). Alles pärast käsupuhvri kirjutamist masinasse saame saata selle järjekorda, mis teadaolevalt juba seadmes on.

Käsupuhvreid on kahte tüüpi: esmane ja sekundaarne. Esmane saadetakse otse järjekorda. Sekundaarset ei saa saata – see käivitatakse esmases. Käsud kirjutatakse samas järjekorras, milles funktsioone kutsuti. Nad sisenevad järjekorda samas järjekorras. Kuid neid saab täita peaaegu "kaootilises" järjekorras. Rakenduses täieliku kaose vältimiseks on Vulkani arendajad pakkunud sünkroonimistööriistu.

Nüüd, kõige tähtsam: peremees Mitte ootab käskude ja käsupuhvrite täitmise lõpetamist. Kõrval vähemalt seni, kuni teete selle selgesõnaliseks. Pärast käsupuhvrite järjekorda saatmist naaseb juhtimine kohe rakendusse.

Seal on 4 sünkroniseerimisprimitiivi: tara, semafor, sündmus ja barjäär.

Tara Lihtsaim sünkroonimismeetod on see, et see võimaldab hostil oodata, kuni teatud asjad juhtuvad. Näiteks käsupuhvri täitmise lõpuleviimine. Kuid tara kasutatakse harva.

Semafor- seadmesisese sünkroonimise meetod. Selle olekut ei ole võimalik vaadata ega masinas oodata, samuti ei saa seda oodata käsupuhvris, kuid saame määrata, milline semafor peaks andma signaali, kui kõik käsklused puhvris on täidetud, ja milline semafor oodake, enne kui hakkate puhvris käske täitma. Ainult, et mitte kogu puhver ei oota, vaid selle teatud etapp.

Torujuhtme etapid ja täitmise sõltuvused

Nagu juba mainitud, ei täideta järjekorras olevaid käske tingimata järjekorras. Täpsemalt öeldes ei oota järgnevad käsud eelmiste täitmist. Neid võib täita paralleelselt või võib eelmise käsu täitmine lõppeda palju hiljem kui järgnevad. Ja see on täiesti normaalne. Aga mõned meeskonnad sõltuvad teiste esinemisest. Saate need jagada kaheks kaldaks: "enne" ja "pärast" ning näidata ka, millised "enne" kalda etapid tuleb enne määratud etappide algust tingimata täita (st käsud ei pruugi olla täielikult või mitte kõik täidetud) täidetakse kaldakäsklused "pärast". Näiteks võib pildi joonistamine teatud toimingute tegemiseks peatada ja seejärel uuesti joonistamist jätkata. Võib olla ka sõltuvuste ahel, kuid ärgem laskugem sügavale Siberi Vulkani metsadesse.

Sündmused- "peenhäälestuse" element. Saate saata signaali nii hostist kui seadmest, samuti saate seadmes ja hostis oodata. Sündmus määrab kahe käskude komplekti (enne ja pärast) sõltuvuse käsupuhvris. Ja ürituse jaoks on ka spetsiaalne pseudolava, mis lubab saatejuhti oodata.

Barjäär jällegi saab kasutada ainult seadmes või täpsemalt käsupuhvris, deklareerides esimese ja teise käsukomplekti sõltuvused. Lisaks saate määrata ka mälutõkkeid, mis võivad olla kolme tüüpi: globaalne barjäär, barjäär puhver ja barjäär Pildid. Need ei võimalda teil kogemata lugeda sisestatud andmeid Sel hetkel kirjutatakse ja/või vastupidi, olenevalt määratud parameetritest.

Konveierid

Allpool on kaks Vulkani torujuhet:

Need. Vulkanil on kaks torujuhet: graafiline Ja arvutuslik. Graafika abil saame loomulikult joonistada ja arvutamisega... arvutada. Mida veel? Seejärel saab arvutustulemused saata graafikakonveierile. Nii saate lihtsalt säästa aega näiteks osakeste süsteemil.

Te ei saa muuta järjekorda ega muuta torujuhtme etappe ise. Erandiks on programmeeritavad etapid (shaders). Samuti saate deskriptorite kaudu varjutajatele (ja mitte ainult) saata erinevat tüüpi andmeid.

Saate luua konveieri jaoks vahemälu, mida saab kasutada (ikka ja jälle) teistes torujuhtmetes ja isegi pärast rakenduse taaskäivitamist.

Enne torujuhtme käskude kasutamist peab konveier olema konfigureeritud ja seotud käsupuhvriga.

Torujuhtme pärand

Kuna konveier on tegelikult kogu info selle kohta, kuidas sissetulevate andmetega töötada, siis võib konveieri muutmine (ja see on varjundite, deskriptorite, rasterdamise jms info) olla ajaliselt kulukas. Seetõttu pakkusid arendajad torujuhtme pärimise võimaluse. Kui vahetate torujuhtme lapse, vanema või laste vahel, väheneb jõudlus. Kuid see on ka mugavus arendajatele, näiteks OOP-ile.

Renderduspääs, graafikakonveier ja kaadripuhver

Niisiis, saame järgmise matrjoška:

Renderduskäskude kasutamiseks vajate graafikakonveierit. Graafikakonveieris peate täpsustama passima andma (Renderda pass), mis sisaldab teavet selle kohta alamkäigud (alampääs), nende sõltuvused üksteisest ja manuseid (manus). Attachment - info pildi kohta, mida hakatakse kaadripuhvrites kasutama. Kaadripuhver luuakse spetsiaalselt konkreetse renderduskäigu jaoks. Läbipääsu alustamiseks tuleb määrata nii läbipääs ise (ja vajadusel alampääs) kui ka kaadripuhver. Pärast passi algust saate joonistada .Saate vahetada ka alamkäikude vahel. Pärast joonistamise lõpetamist saate passi lõpule viia.

Mälu haldamine ja ressursid

Mälu Vulkanis eraldab host ja ainult host (välja arvatud vahetusahel). Kui seadmesse on vaja paigutada pilt (või muud andmed), eraldatakse mälu. Kõigepealt luuakse teatud suurusega ressurss, seejärel küsitakse selle mälunõudeid, eraldatakse sellele mälu, seejärel seostatakse ressurss selle mälu lõiguga ja alles siis saab sellesse ressurssi kopeerida vajalikud andmed. Samuti on mälu, mida saab otse hostist muuta (host on nähtav), on olemas kohalik mälu seadmed (näiteks videokaardi mälu) ja ka muud tüüpi mälud, mis omal moel mõjutavad neile juurdepääsu kiirust.

Vulkanis saate kirjutada ka oma hosti mälujaotuse, seadistades tagasihelistamise funktsioonid. Kuid pidage meeles, et mälunõuded pole mitte ainult selle suurus, vaid ka tasandamine (joondus).

Ressursid ise on kahte tüüpi: puhvrid (puhvrid) Ja Pildid (pilte). Mõlemad on eraldatud eesmärgi järgi, kuid kui puhver on lihtsalt erinevate andmete kogum (tipp, indeks või konstantne puhver), siis on pildil alati oma formaat.

Nõuanded neile, kes Vulkanist kirjutavad

Määrake mäluala, kuhu saate korraga paigutada mitu ressurssi. Eraldamiste arv on piiratud ja teil ei pruugi olla piisavalt. Kuid ühenduste arv ei ole piiratud.

Varjutajad

Vulkan toetab 6 tüüpi varjutajaid: apikaalne, tessellatsiooni juhtimine, tessellatsioonianalüüs, geomeetriline, fragmentaarne(teise nimega piksel) Ja arvutuslik. Saate need kirjutada loetavale SPIR-V-le ja seejärel baitkoodiks kokku panna, mille me sulgeme rakenduses mooduliks, st. Loome sellest koodist varjundimooduli. Loomulikult saame selle kirjutada tavalises GLSL-is ja seejärel teisendada selle SPIR-V-ks (meil on juba tõlkija). Ja loomulikult saate kirjutada oma tõlkija ja isegi koostaja - allikad ja spetsifikatsioonid on avaldatud OpenSource'is, miski ei takista teil oma kõrgetasemelise SPIR-V jaoks koostajat kirjutada. Või äkki on keegi selle juba kirjutanud.
Seejärel tõlgitakse baidikood iga videokaardi jaoks spetsiifilisteks käskudeks, kuid seda tehakse palju kiiremini kui GLSL-i töötlemata koodi puhul. Sarnane praktika kehtib ka DirectX-i kohta – HLSL teisendatakse esmalt baitkoodiks ning selle baidikoodi saab salvestada ja seejärel kasutada, et mitte varjutajaid ikka ja jälle kompileerida.

Aknad ja ekraanid

Ja see artikkel lõpeb looga WSI-st (Window System Integration) ja lülitusahelast (swapchain). Et midagi aknas või ekraanil kuvada, on vaja spetsiaalseid laiendusi.

Akende jaoks on see põhipikendus igale süsteemile omane tasapind ja tasandi laiendus (win32, xlib, xcb, android, mir, wayland). Ekraan (st täisekraan) nõuab kuvalaiendit, kuid üldiselt kasutavad mõlemad vahetusahela laiendit.

Lülituskett ei ole graafikakonveieriga ühendatud, nii et lihtne Clear Screen töötab ilma seda kõike konfigureerimata. See on üsna lihtne. On olemas teatud esitlusmootor, millel on piltide järjekord. Ekraanil näidatakse üht pilti, teised ootavad oma järjekorda. Samuti saame määrata piltide arvu. Samuti on mitu režiimi, mis võimaldavad oodata vertikaalset sünkroonimissignaali.

See toimib umbes järgmiselt: taotleme tasuta pildi indeksit, kutsume käsupuhvri, mis kopeerib tulemuse kaadripuhvrist sellele pildile, ja saadame käsu saata pilt järjekorda. See kõlab lihtsalt, kuid arvestades, et sünkroonimine on vajalik, on kõik veidi keerulisem, kuna host ootab ainult pildi indeksit varsti on saadaval. Käsupuhver ootab semafori signaali, mis annab märku pildi saadavusest, ja saadab siis ise läbi semafori signaali, et puhvri täitmine ja järelikult kopeerimine on lõpetatud. Ja pilt läheb tegelikult järjekorda viimase semafori signaaliga. Seal on ainult kaks semafori: pildi saadavuse kohta kopeerimiseks ja pildi saadavuse kohta kuvamiseks (st kopeerimise lõpetamise kohta).

Muide, kontrollisin, et sama käsupuhver saadeti järjekorda tõepoolest mitu korda. Võite ise mõelda, mida see tähendab.

Selles artiklis püüdsin rääkida Vulkani API kõige olulisematest osadest, kuid palju on ikka veel käsitlemata ja saate ise teada. Soovin teile stabiilset FPS-i ja meeldivat kodeerimist.

3D-rakenduste, videomängude ja süsteemide arendamisel Virtuaalne reaalsus tuleb uus etapp. Koos tegid arendajad oluline samm teel koodide ühtlustamise ja muu poole tõhus kasutamine riistvararessursse. Khronos Group, üle saja ettevõtte konsortsium, on ametlikult avalikustanud avatud platvormidevahelise API esimese versiooni nimega Vulkan (endine GLNext). See võimaldab GPU ja CPU üle otsest juhtimist, kõrvaldades kitsaskohad ja parandades üldist jõudlust.

Foorumites näete sageli sama tüüpi küsimusi selle kohta, kas protsessor X avab videokaardi Y ja milline sama eelarvega konfiguratsioon on produktiivsem konkreetsed rakendused. Selle põhjuseks on asjaolu, et tänapäevastel GPU-del on suurem jõudlus kui sama taseme ja põlvkonna protsessoritel. Mängudes ja muudes 3D-rakendustes võib juhtuda, et protsessor peab seda tegema tohutu surve ja perearst on jõude. Näiteks arvutab protsessor mängijate ja objektide interaktsiooni ning videokaart ootab sealt andmeid, et järgmine kaader joonistada. Koormuse tasakaalustamatuse tõttu tekivad viivitused ja dünaamiline mäng võib muutuda kaadri kaupa slaidiesitluseks isegi võimsa videokaardiga.

Need probleemid on tüüpilised personaalarvutiplatvormile ja on mängukonsoolide omanikele praktiliselt tundmatud. Konsoolimängude arendajad teavad alati konsoolide üksikasjalikke spetsifikatsioone ja saavad nende funktsioone arvesse võttes läbi viia sügava koodi optimeerimise. Arvutid, sülearvutid, tahvelarvutid pole mitte ainult erinevate konfiguratsioonide, vaid ka põhimõtteliselt erineva arhitektuuriga loomaaed. Nii mitmekesise platvormi jaoks mängude loomisel muutub prioriteediks koodi universaalsus, mis mõjutab negatiivselt selle täitmise kiirust.

Arendajad operatsioonisüsteemid nad püüavad lahendada koodi madala efektiivsuse probleemi erinevatel viisidel kolmanda osapoole rakendused. Microsoft hakkas juba ammu otsima võimalusi graafikaarvutuse optimeerimiseks, kuid tegelik tugi madala tasemega operatsioonidele ilmus alles DirectX 12-s. See API on saadaval ainult ühes OS-is – Windows 10-s. Apple'i positsioon osutus mängukonsoolitootjate omale lähedasemaks. Kui sama ettevõte toodab mobiilseid protsessoreid ja tarkvara, on koordineeritud tööd palju lihtsam saavutada. Apple ei ole aga kaugeltki ammendanud võimalusi mängude ja rakenduste arendamise optimeerimiseks. Ilmus iOS 8-s Metallist API, mis keskendus ka madala taseme operatsioonide kasutamisele.

Puhka suured ettevõtted eelistavad tegutseda koostöös ja avatud standardite piires. 16 aastat tagasi ilmunud Khronos Groupi konsortsium ühendas enam kui sada tootjat, kelle hulgas oli ka selliseid veresõpru nagu AMD, Nvidia ja Intel. Omal ajal tõi konsortsium päevavalgele avatud standardid OpenGL, OpenCL, OpenCV ja paljud teised.

Võrreldes OpenGL-iga annab Vulkan arendajatele võimaluse kasutada madala tasemega toiminguid ilma koodi teisaldatavust kahjustamata. Vulkani kasutamine sees erinevad platvormid on võimalik saavutada peaaegu sama tasakaalustatud algoritm nagu spetsialiseerunud mängukonsoolid. See API aitab teil riistvara võimalusi paremini kasutada diskreetsed videokaardid ja integreeritud graafikakiibid 2D- ja 3D-režiimides.

Sarnaselt DirectX 12-ga toetab Vulkan otsest juurdepääsu GPU mälule. Lisaks vähendab Vulkan renderduskiiruse sõltuvust draiverite kvaliteedist. Tõlkides varjutusprogrammide koodi vahepealsesse binaarvormingusse, saab nende koostamist teostada juba arendusfaasis, mitte 3D-rakenduse käivitamise ajal.

Vulkan on olnud arenduses alates 2014. aasta keskpaigast. See põhines graafika raamatukogud veel üks madala taseme API - AMD Mantle. AMD oli ka ametlike spetsifikatsioonide toimetaja. Lisaks neile avaldas Khronos grupp mitmeid teste, mis demonstreerisid uue API eeliseid. Kõik need on saadaval GitHubi portaalis.

"Vulkanil on tohutu potentsiaal," ütleb Croteami programmeerija Dean Sekulic. – Ühe lausega öeldes lõpetas Vulkani tulek koodi jõudluse ja kaasaskantavuse eest võitlejate pikaaegse vastasseisu. Nüüd teisaldame sellesse The Talos Principle'i, et kinnitada uut arenduskontseptsiooni.

Valve sponsoreerib avatud LunarG SDK loomist API tugi Vulkan. Kuid vaatamata avatud spetsifikatsioonidele, olemasolevatele arendustööriistadele, võimalus sügav optimeerimine koodi ja muid eeliseid, on Vulkan mõnda aega harva kasutatav API. Enamik mängude tegijaid jääb truuks DirectX 11/12-le ja OpenGL-ile. Seda on palju lihtsam suurendada Nõuded süsteemile või pigem graafika kvaliteeti vähendada kui uusi arendusmeetodeid omandada. Sellest aru saades püüab Khronos Groupi konsortsium pakkuda Vulkanile tuge mitte ainult uutes operatsioonisüsteemides ja graafilised lahendused, aga ka vananenud süsteemide puhul.

Vulkan on praegu toetatud Windowsi keskkond(alates seitsmendast versioonist), Linux, SteamOS ja Android. Samsungi Tizen OS-i tugi peaks peagi lisanduma. AMD ja Nvidia on juba välja andnud draiverite beetaversioonid, mis toetavad Vulkan API-t. Järgmiseks on Intel, Qualcomm, ARM ja teised tootjad, kes kuuluvad Khronos Groupi konsortsiumi. Vulkani demo ARM Mali graafikakiibil on näha allolevas videos.

Praegu saab Vulkanit videokaartidel testida graafika kiibid Nvidia GeForce GT 630 ja uuemad, AMD Radeon HD 7700 ja uuemad. Vulkan API toetab ka hübriidi AMD protsessorid Koos graafika tuum Radeon HD 8500 – 8900 ja R2 – R9. Sisseehitatud graafika töölauale ja mobiilsed protsessorid Intel on Vulkanit toetanud sellest ajast peale Põhiperekond viies põlvkond.

Uue API täielikud võimalused paljastatakse paljutõotava graafilise abil Nvidia protsessorid Pascali seeria ja AMD neljanda põlvkonna GCN-i arhitektuuriga. Eeldatavasti lisatakse vastavad videokaardid GTX seeria 1xxx ja Radeon Rx 400. Nende müügi algus on mitteametlikel andmetel planeeritud 2016. aasta teise kvartalisse.

Vulkan on uus API 3D-rakenduste loomiseks. Selle töötas välja Khronos Group, kes arendab ka OpenGL-i. Suur panus API loomine investeerinud AMD ettevõte. Kuigi selle kallal töötasid paljud teised ettevõtted, näiteks Microsoft, Apple, Google, Sony. Seda API-d toetavad sellised riistvara loojad nagu: NVidia, AMD, Intel, Qualcomm, Imagination Technologies, ARM.

Mille poolest Vulkan erineb OpenGL-ist

Wikipedia artikkel toob välja 4 peamist erinevust:

1. Globaalseid riike pole olemas, kõik riigid on seotud objektidega.
2. Olekud on seotud käsupuhvriga, mitte kontekstiga nagu OpenGL-is.
3. OpenGL-is ei tehta mälu haldamist ja sünkroonimist otseselt, Vulkanis saab arendaja seda juhtida.
4. Veakontrolli puudumine draiveris töö kiirendamiseks.

Lähtudes sellest, et uus API on ilmunud täna ja Khronos Group on seda 18 kuu jooksul arendanud tihedas kontaktis maailma juhtivate IT-ettevõtetega, võime järeldada, et see API peaks sobima paremini tänapäevaste 3D rakenduste jaoks.

Allpool näete, kuidas Vulkan töötab:

Kas Vulkan tuleb Mac OS X-i?

Kui Vulkani spetsifikatsioon on avaldatud, leidke draiverid kaasaegsed videokaardid ei ole raske. Kuid see kehtib ainult Windowsi ja Linuxi jaoks. Kuna Vulcan on ainult platvormideülene API, mis ei vaja videokaartidelt erilist tuge, saate draiverit värskendades seda kasutama hakata (kui teie videokaart on muidugi toetatud loendis).

Mac OS X puhul on asjad palju keerulisemad. El Capitanis pole Vulkani tuge, tahaks sisse oodata järgmised versioonid, aga on üks "aga". Apple on lisanud El Capitanile toe oma API-le - Metal. Varem kasutati seda ainult iOS-i seadmete jaoks. Selle põhjal ja arvestades ka asjaolu, et Apple on harjunud kontrollima kõike, mis nende seadmeid puudutab, võime järeldada, et Vulkan ei pruugi Mac OS X-is ilmuda.

Mis järgmiseks?

Minu arvates sõltub Vulkanit ees ootav suuresti sellest, kui aktiivselt arendajad seda kasutama hakkavad ja videokaartide tootjatelt toetama hakkavad. Kui OpenGL-i arendamine siin peatub, siis pole uute rakenduste jaoks enam valikut ja neid tuleb arendada Vulkanis. Kuid on tuhandeid OpenGL-i rakendusi, mida keegi kohe Vulkanis ümber kirjutama ei torma. Ka Mac OS X probleem pole selge, kuna see on USA-s väga levinud süsteem. Kui Mac OS X jaoks on olemas Metal, Windowsi jaoks DirectX ja Linuxi jaoks Vulkan, siis ei hõlbusta Vulkan mingil juhul platvormidevaheliste rakenduste arendamist.