Relatief recent is er een nieuwe uitgekomen Vulkan-API- 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 voorkomen dat u per ongeluk de gegevens leest die momenteel 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.
Testbank nr. 2 gebaseerd op het Intel Socket 2011-platform
Testbank nr. 3 gebaseerd op het Intel Socket 1155-platform
Testbank nr. 4 gebaseerd op het AMD Soket AM3+ platform
Testbank nr. 5 gebaseerd op het Intel Socket 1150-platform
Alle videokaarten zijn getest maximale kwaliteit afbeeldingen MSI-programma Naverbrander. Het doel van de test is om te bepalen hoe videokaarten werken diverse fabrikanten onder dezelfde omstandigheden. Hieronder vindt u een video van het testsegment:
Onze videokaarten zijn getest met resoluties van 1920x1080, 2560x1600 en 3840x2160 bij maximale instellingen grafische kwaliteit toegestaan door Doom. AMD CrossFireX en SLI worden niet volledig ondersteund door de game en we hebben ze in de test niet geactiveerd. We raden zelfs aan CrossFireX uit te schakelen, omdat de prestaties aanzienlijk afnemen als het wordt geactiveerd.
Testen bij maximaal kwaliteitsinstellingen 1920x1080 API OpenGL
Testen bij maximaal kwaliteitsinstellingen 1920x1080 API Vulkan
Acceptabel met deze instellingen FPS-indicator toonde videokaarten van het Radeon R7 370-niveau of GeForce GTX 750 Ti.
Testen bij maximaal kwaliteitsinstellingen 2560x1440 OpenGL-API
Met deze instellingen vertoonden videokaarten van het Radeon R7 370- of GeForce GTX 750 Ti-niveau acceptabele FPS.Radeon HD 7950 of GeForce GTX 770.
Testen bij maximaal kwaliteitsinstellingen 2560x1440 API Vulkan
Met deze instellingen vertoonden videokaarten van het Radeon R7 370- of GeForce GTX 750 Ti-niveau acceptabele FPS.Optimale oplossingen zal worden Radeon R7 370 of GeForce GTX TITAN.
Testen bij maximaal kwaliteitsinstellingen 3840x2160 OpenGL-API
Met deze instellingen vertoonden videokaarten van het Radeon R9 290- of GeForce GTX 970-niveau een acceptabele FPS. De optimale oplossingen zouden zijn videokaarten van het Radeon R9 290X- of GeForce GTX 980-niveau.
Testen bij maximaal kwaliteitsinstellingen 3840x2160 API Vulkan
Met deze instellingen vertoonden videokaarten van het Radeon R9 380X- of GeForce GTX 970-niveau een acceptabele FPS. De optimale oplossingen zouden zijnvideokaarten van het Radeon R9 290- of GeForce GTX 970-niveau.
Uit deze resultaten kunnen verschillende conclusies worden getrokken. AMD-videokaarten in de Vulkan API zorgen voor een aanzienlijke prestatieverbetering, terwijl NVIDIA minimaal is (de Kepler-familie staat over het algemeen in het rood), blijkbaar moet je wachten op nieuwe stuurprogramma's.
Het is ook vermeldenswaard dat De Vulkan API kan alleen efficiënt gebruik maken van het geheugen van de videokaart, en als het spel meer verbruikt, dan dalen de prestaties van de videokaarten naar een onspeelbaar niveau...
Het programma heeft het door het spel verbruikte videogeheugen getest MSI-naverbrander. De indicator was gebaseerd op de resultaten top videokaarten van AMD en NVIDIA met resoluties 1920x1080 en 2560x1440 met verschillende anti-aliasing-instellingen.
Testen met maximale geheugen-GPU-kwaliteitsinstellingen
De aanbevolen hoeveelheid videogeheugengebruik voor een resolutie van 1920x1080 is 3076 MB videogeheugen, voor een resolutie van 2560x1440 - 3076 MB videogeheugen, en voor een resolutie van 3840x2160 ongeveer 4096 MB videogeheugen.
We hebben de processorafhankelijkheid getest op 16 modellen van basisconfiguraties die vandaag relevant zijn. De test is uitgevoerd op die plekken waar de videokaartwaarde voor de game minimaal is en de belasting minder dan 99% is, dit keer met een resolutie van 1920x1080.
Testen op maximale kwaliteitsinstellingen 1920x1080 OpenGL-API
Testen op maximale kwaliteitsinstellingen 1920x1080 API Vulkan
Processorprestaties in het spel op met behulp van de API Vulkan groeit niet alleen, maar elimineert ook problemen waarbij de prestaties achteruit gingen als gevolg van een teveel aan processorkernen.
Doom gebruikt maximaal 16 threads, maar slechts 4 kernen worden volledig benut.
De test werd uitgevoerd op een basis Kernconfiguraties i 7 5960X@4,6 GHz met hoeveelheid vooraf ingesteld geheugen 32 GB DDR4 2400 MGz. Het gehele gebruikte operatieve geheugen werd als indicator genomen. Test RAM het hele systeem werd uitgevoerd op verschillende testbanken zonder applicaties van derden te starten (browsers, enz.).
Het RAM-verbruik van de game testen op verschillende instellingen kwaliteit
Zoals we kunnen zien, ligt de hoeveelheid RAM die in Doom wordt verbruikt binnen de 3000 megabytes.
Testen van het RAM-verbruik van het systeem
Op een systeem van 6 GB verbruikt Doom alle 5,5 GB RAM. Bij een systeem met 8 gigabyte bedroeg het RAM-verbruik van het gehele RAM-geheugen 6 gigabyte. Met een systeemverbruik van 16 GB gedeelde herinnering bedroeg bijna 7 gigabyte. En met 32 gigabyte RAM verbruikt het systeem 7,2 gigabyte RAM.
Dit zijn totaal verschillende dingen.
Het is noodzakelijk om onderscheid te maken tussen studeren API, van studeren technologieën. Als je alleen maar de API wilt leren, leer dan alles, want je merkt het verschil pas als je het begrijpt basis, basis.
OpenGL is ontworpen toen er nog andere hardware-architecturen waren. Multiprocessing bestond alleen in theorie en werd beschouwd als het domein van supercomputers en onnodig voor consumenten-pc's.
Er kan een analogie worden gegeven: OpenGL == C++, Vulkan == asynchrone Assembler + hardwarethreads. In C++ zijn er nu bijvoorbeeld behoorlijk wat architectonische problemen die ze proberen op te lossen met nieuwe standaarden, waarbij ze sommige dingen achterhaald verklaren omdat ze conceptueel onjuist zijn en niet passen in de moderne realiteit.
Maar tegelijkertijd kun je hetzelfde in assembler schrijven, maar je moet veel beter begrijpen hoe de processor en het besturingssysteem werken, zelf synchronisatieprimitieven schrijven, enz.
De vulkaan is voor dezelfde doeleinden gemaakt. Om erop te programmeren, moet je alle fijne kneepjes van de hardware kennen, een heleboel artikelen van dezelfde NVidia lezen, onderzoek doen, nieuwe functies bedenken voor moderne architecturen helemaal opnieuw, die oorspronkelijk zijn uitgevonden in OpenGL, maar dan voor oude hardware.
Dat wil zeggen, op Vulcan moet je doen meer met je handen, optimaliseer meer. In plaats van één telefoontje OpenGL-functies, zul je honderden regels op de vulkaan moeten schrijven. Tegelijkertijd, als je één subtiliteit niet begrijpt, maak je iets minder efficiënt dat oorspronkelijk goed geïmplementeerd was in OpenGL. Bovendien kan OpenGL fouten veroorzaken als u ergens een fout maakt. Vulcan gooit ze niet weg; het is afhankelijk van het feit dat je al weet hoe je het moet gebruiken. Net zoals assembler eenvoudigweg de status van registers verandert, kent het geen concept van fouten. Hoe deze registers moeten worden geïnterpreteerd, hangt af van hoe goed de ontwikkelaar de processorhandleiding heeft gelezen.
Uiteindelijk zou ik als volgt antwoorden:
Als je graphics als een wetenschap studeert, als student a la Carmack wild nerd met zijn motoren, iets onderzoekt, briljante algoritmen schrijft, dissertaties hierover verdedigt, publiceert en vervolgens op een conferentie vertelt hoe cool je met een urgente taak bent omgegaan , verhoogde productiviteit, leer dan Vulkan. Vulkan gaat over graphics als technologie, over prestaties, over engineering en architectonisch ontwerp, en niet over API's en programmeren zelf. Met een vulkaan zul je meer tijd moeten besteden aan diagrammen, documentatie en het bouwen van een architectuur, waarbij je methoden moet bedenken om delen van deze architectuur met elkaar te laten communiceren, toestanden te synchroniseren, in plaats van code te schrijven.
Als u eenvoudige, toegepaste dingen schrijft die een of andere vorm van afbeeldingen moeten weergeven, leer dan OpenGL. Hier leer je alleen de API, akkoord met een kant-en-klaar, enigszins verouderd, architectonisch ontwerp.
Als je games van niet-wereldklasse wilt schrijven, leer dan kant-en-klare engine, Unity of Unreal. Zij ondersteunen Vulkan al voor je, hebben de API en architectuur voor je uitgedacht.
Voordat we het hebben over de details en fijne kneepjes van de Vulkan API, denk ik dat we eerst een paar woorden moeten zeggen over wat het is en waarvoor het wordt gebruikt. Als je Linux vergelijkt met Windows, dan is Vulkan (dat nog in ontwikkeling is) Directx, een reeks bibliotheken voor het verbeteren van de prestaties, voornamelijk in computerspellen. Zoals bekend, op Linux-platform, kun je games uitvoeren met , PlayOnLinux of commerciële versie. Maar niet al het speelgoed zal correct starten en werken, en dat allemaal vanwege de verdomde Directx API.
Ik vergat te zeggen dat voor prestaties in games voor .nix-platforms OpenGL vergelijkbaar wordt gebruikt software, zoals Directx voor Windows. Dus Vulkan API, zoals gerapporteerd door ontwikkelaars van Nvidia(die op hun beurt ook geïnteresseerd zijn in de implementatie van dit project) Vulkan API zal worden aangevuld met oudere OpenGL. Dit betekent op zijn beurt dat minder resource-intensieve objecten zullen worden verwerkt met behulp van OpenGL, en wanneer de tijd daar is, zal dit een rol gaan spelen nieuw project.
Voordeel van Vulkan-API
Waarom wordt dit project zo gesteund? gerenommeerde bedrijven, waaronder Intel, AMD, Nvidia, enz. Wat is het mooie van de nieuwe API? Hier moet je een video laten zien die duidelijk laat zien hoe het in de praktijk is...
Zoals je in de video hierboven kunt zien, beheert de Vulkan API CPU-multitasking zeer goed, wat je op zijn beurt in staat stelt de GPU effectief te beheren, waardoor de belasting gelijkmatig wordt verdeeld, wat heel goed blijkt goed resultaat qua productiviteit. In OpenGL gaat alle belasting naar CPU, en FPS zakt merkbaar, in de Vulkan API wordt alles verstandig gedaan, de belasting wordt verdeeld en FPS zakt nog steeds, maar veel minder vaak.
Vooruitzichten voor de ontwikkeling van Vulkan API
Helaas, exacte datum release is nog onbekend, en welke games ondersteuning zullen krijgen voor de nieuwe API worden ook geheim gehouden. AMD (dat nu zeer actief samenwerkt met ontwikkelaars) liet op zijn beurt doorschemeren dat ze eraan werken nieuw spel, die de Vulkan API zal gebruiken, anders zal een game worden geport.
Ik vergat te vermelden dat het nieuwe project platformonafhankelijk zal zijn en dat zelfs Android ermee zal werken.
Verder nieuws over het Vulkan API-project wordt van 14 tot 18 maart bekendgemaakt tijdens The Game Developers Conference (GDC).
Laat al je gedachten over Vulcan achter in de reacties. Het zal heel interessant zijn om te zien of Linux dat ook zal worden spelplatform of Windows komt weer met iets bovennatuurlijks.
Vertaling, commentaar: alfabuster, speciaal voor de site
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. Consortium Khronos-groep, dat meer dan honderd bedrijven heeft, heeft officieel de eerste versie geïntroduceerd 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 is gebaseerd op de grafische bibliotheken van een andere API op laag niveau: AMD Mantle. AMD-bedrijf diende 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 AMD hybride 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.
Het volledige potentieel van de nieuwe API zal worden onthuld door beloftes te doen GPU's Nvidia-serie Pascal en AMD met de 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.
