Vulkan 1.1-specifikation udgivet: Åbent kildeværktøjer, SDK'er og Launch Driver Support

Siden udgivelsen af Vulkan 1.0 i februar 2016 kom efterfølgeren til OpenGL langsomt men sikkert til applikationer og spilmotorer. I dag, cirka to år senere, frigiver Khronos-koncernen Vulkan 1.1- og SPIR-V 1.3-specifikationerne og ligner Vulkan 1.0s hårde API-lancering. Disse ledsages af opdaterede udviklerværktøjer, open source-konformitetsprøver og lancering af driverstøtte fra GPU leverandører.

Selvom vedtagelsen måske ikke har været så hurtig som nogle brugere ville have ønsket, var Vulkan 1.0s funktionssæt og funktionalitet aldrig problemet. I modsætning til den Microsoft-understøttede DX12 og Apple-støttede Metal består Khronos Group-industrikonsortiet af medlemsvirksomheder, der ratificerer specifikationer, og tilbyder ikke den samme slags fælles udviklingsressourcer, værktøjer og vejledninger.

Med det i betragtning, hvor 1.0 primært understregede softwaren og specifikationerne selv, er Vulkan 1.1-udgivelsen kombineret med videreudvikling af Vulkan-økosystemet, hvor Khronos annoncerer et nyt offentligt "Vulkan Ecosystem Forum" for at lette udviklerens feedback og samarbejde. Og det hænger også sammen med Khronos bestræbelser på at udvide platformsstøtten, hvor i sidste uge en open-source samling af værktøjer og biblioteker blev frigivet til porten Vulkan applikationer til macOS og iOS, som en del af Vulkan Portability Initiative.

Samlet set er udviklingen af ​​Vulkan fra 1.0 til 1.1 trekantet: integration af udvikler-anmodede funktionaliteter, driverstøtte og sømløs transmission af Vulkan til flere platforme og derefter praktisk implementering ved hjælp af et udviklet økosystem.

Vulkan 1.1 Spec Highlights

Flytning direkte ind i kernen ændrer Vulkan 1.1 to nye omfattende funktioner: beskyttet indhold og undergruppe operationer. Den førstnævnte bruger begrænsninger på lavt niveau, således at applikationer kan gengive og vise ved hjælp af ressourcer, som de ikke kan få adgang til eller kopiere, hvilket igen sikrer afspilning og visning af beskyttet indhold. Selvom det tilsyneladende var DRM-formål, bemærkede Khronos, at Vulkan udsatte GPU-kapacitet frem for at skubbe til hardware-niveau DRM, hvilket efterlod brug eller implementering op til udviklerne.

Så på den ene side kan udviklere vælge at skabe en stærkt restriktiv multi-layer DRM-skema med en høj grad af granularitet. På den anden side kan funktionen måske bruges til en avanceret adblocker på lavt niveau, ikke kun til browsere, men også til ad-servering af mobile og stationære spil og applikationer. Alt kan være muligt med Vulkan 1.1 og videre. Til det formål søger Vulkan på mange måder blot at aktivere, hvad der er muligt - i reneste forstand - på GPU'er.

Denne idé fortsætter med de nye "undergruppeoperationer", hvor et sæt tråde kan kommunikere og koordinere indbyrdes, hvor normalt dette ville ske ved at få adgang til off-chip-hukommelse. I sidste ende giver dette udviklere en metode til parallelisering af visse arbejdsbyrder i meget høj grad, og mens beregning og dyb læring er de mere oplagte anvendelsessager, er undergruppeoperationer ikke begrænset til kun beregning af shaders og kan formodentlig anvendes til grafiske formål. Naturligvis understøtter den nye SPIR-V 1.3 ligeledes undergruppeoperationer. (ed: dette lyder meget Volta-ish, selvom jeg forventer, at fremtidige GPU'er også implementerer den underliggende teknologi)

De andre 1.1-kerneintegrationer kommer fra allerede eksisterende udvidelser, som nu fremmes til det mest integrerede niveau af udvidelser inden for API'en. Mange af disse udvidelser er fokuseret på VR eller forbedret alsidighed af en slags, herunder samtidig gengivelse til flere billedvisninger (f.eks. multi-projektion acceleration), cross-API og cross-application / process interoperabilitet, YCbCr support og enhed grupper til homogene multi-GPU konfigurationer.

Støbning af et Vulkan-økosystem: Mere support, bedre værktøjer

For alle specifikationer og funktioner er Vulkan stadig en API, der driver andre applikationer, motorer og spil. I de to år siden Vulkan 1.0s udgivelse har en række nye Vulkan-powered mobile og cross-platform desktop spil fortsat med at udlede; Samtidig med at anerkende de potentielle problemer med at citere Wikipedia, påpeger Khronos, at der er sammenlignelige mængder DX12 og Vulkan-aktiverede spil i stedet for et betydeligt DX12-flertal. Ved vores egen regning er der helt sikkert flere AAA Windows-spil, hvor DX12 er den foretrukne API, men takket være den langsomme adoptionshastighed på begge sider, er det næsten ikke så skævt som Direct3D vs OpenGL var.

Men som en proprietær løsning understøttet monolitisk af Microsoft, har DX12 en bred vifte af centraliserede og eksisterende ressourcer. Derudover kan DX12 skubbes direkte ved hjælp af Microsoft Studios og UWP. I mellemtiden er Khronos et industrikonsortium og har naturligvis ikke egen udviklingskapacitet eller tilbyder den slags direkte udviklerstøtte.

Doubling-down på open source-tilgangen genopretter Khronos ligeledes et åbent økosystem med det nye "Vulkan Ecosystem Forum." At være i kommunikation med udviklere fra andre platforme samt API-designere og arbejdsgrupper af Vulkan i sig selv, ville forummet ideelt set bringe en grad af centralisering og kilde til aktiv udvikler fremskridt uden at pålægge et specifikt mandat, ligesom Vulkan spec selv. Som flere platforme bringes i fold, gennem Vulkan Portability Initativt eller på anden måde, kan forummet fungere som en centraliseret kilde til krydsbestøvning for multi-platform udviklere. Forumet vil også tilbyde open source-projekter med vedvarende vejledning, hvilket ville være særligt nyttigt for mindre projekter, som kunne blive meget nyttige.

Denne tilgang kræver også mere guider, ressourcer og værktøjer, da de ikke ville blive gennemgået, pakket og støttet monolitisk. På den måde annoncerer Khronos og LunarG adskillige nye Vulkan-udviklerværktøjer, herunder et Device Simulation Layer. Og med mere end to års erfaring med Vulkan 1.0 og dens idiosyncrasies har Khronos og LunarG gjort deres bedste praksis tilstrækkelige til at gøre et assistentlag til at guide både nyere og ældre udviklere med situationer, der ikke er direkte dækket eller forbudt af Vulkan spec.

Det andet punkt, at Khronos gentog, var på konkurrence mellem Vulkan og DX12. I stedet for at kollidere fra hoved til hoved, ser Khronos, at hver API har forskellige brugssager og styrker med en vis overlapning. For UWP-kun-udviklere er der ringe grund til at overveje Vulkan, mens udviklere, der søger at distribuere på tværs af flere platforme, muligvis ikke ønsker at begrænse sig med DX12. Med Vulkan Portabilitetsinitiativet og især gfx-r'er sigter Khronos på at implementere Vulkan over D3D12, Metal og OpenGL.

Mens nogle har opfattet disse Vulkan-bærbare delsæt som et andet eksempel på en universel standard, der kun bliver en anden konkurrerende standard, nævnte Khronos udtrykkeligt at undgå denne tilgang. På grund af de samme forhold mellem Metal, DX12 og Vulkan, samt Vulkans modularitet med lag og iboende cross-vendor tværplatform alsidighed, kan Metal og DX12 behandles som undergrupper af Vulkan. På den måde kan Khronos forenkle ligningen ved at give udviklere mulighed for at bygge videre på Vulkan og nemt porte det andetsteds.

På disse måder tackler Khronos det, de ser som deres største hindring, Vulkan økosystemet. Fremadrettet skitserede Khronos en generel 1 til 2 års kadence for Vulkan-kerne og tilsvarende SPIR-V-opdateringer, hvor udvidelser blev prøvet, integreret og debugged hele tiden.

Hvad angår lanceringsdrivere bemærkede Khronos, at AMD, Arm, Imagination, Intel, NVIDIA, og Qualcomm alle havde overensstemmende Vulkan 1.1 drivere. Links vil blive opdateret, da de bliver tilgængelige.

Økosystemforummet findes på sin specifik GitHub side, mens den opdaterede LunarG SDK og værktøjer lag er også tilgængelige. Alle Khronos open source-projekter kan findes gennem den generelle GitHub.

Oprindelig artikel

Giv en kommentar

Dette websted bruger Akismet til at reducere spam. Lær, hvordan dine kommentardata behandles.