Khronos brengt 1.1-versie van Vulkan uit

De Khronos Group heeft versie 1.1 van de Vulkan-api uitgebracht. Deze release integreert veel functies die in de vorige versie als extensies beschikbaar waren. Daarnaast zijn er nieuwe functies zoals operaties in subgroepen en ondersteuning van beschermde inhoud bijgekomen.

Khronos schrijft bij de bekendmaking van de release dat deze gepaard gaat met versie 1.3 van SPIR-V en dat hij veel functies bevat waar ontwikkelaars om vroegen. Eén daarvan wordt aangeduid als subgroup operations, waarbij verschillende taken die op een gpu draaien onderling gegevens kunnen uitwisselen en aanpassen. Er is ondersteuning voor verschillende modellen voor parallel computations, zo beschrijft de eveneens uitgebrachte presentatie met de belangrijkste vernieuwingen. De specificatie is eveneens te raadplegen.

Een andere vernieuwing is dat versie 1.1 het mogelijk maakt voor applicaties om beschermde inhoud weer te geven. Daarbij is bijvoorbeeld te denken aan drm, al merkt AnandTech op dat Khronos het aan de ontwikkelaars laat hoe ze deze functie gebruiken of implementeren. In de aankondiging wordt de ondersteuning voor beschermde inhoud omschreven als de mogelijkheid voor applicaties om bijvoorbeeld rendering uit te voeren met resources waar ze niet bij kunnen of die ze niet kunnen kopiëren.

De integratie van eerdere extensies breidt zich uit over de mogelijkheid om meerdere beeldweergaven in één keer te renderen, ondersteuning voor Microsofts hlsl-taal, het delen van geheugen met verschillende api's binnen één of meerdere applicaties en het aanmaken van apparaatgroepen voor ondersteuning van meerdere identieke gpu's binnen een enkel systeem. Deze integraties moeten bijvoorbeeld ook ten goede komen bij vr-toepassingen.

Onlangs maakte de Khronos Group bekend dat het met de hulp van Valve was gelukt om tools opensource te maken die gebruikt kunnen worden voor Vulkan-ondersteuning op macOS en iOS door calls te vertalen naar Appels eigen Metal-api. Vulkan is een lowlevel-api voor het aansturen van de gpu. De api is grotendeels afgeleid van AMD's Mantle en geeft direct toegang tot diepere lagen van grafische hardware, zodat de overhead wordt verminderd. De Khronos Group is een consortium waarin tal van bedrijven zijn vertegenwoordigd. Diverse bedrijven steunen de groep of dragen zelf bij aan de ontwikkeling van de Vulkan-api.

Reacties (26)

[TimMer]

Een andere vernieuwing is dat versie 1.1 het mogelijk maakt voor applicaties om beschermde inhoud weer te geven. Daarbij is bijvoorbeeld te denken aan drm, al merkt AnandTech op dat Khronos het aan de ontwikkelaars laat hoe ze deze functie gebruiken of implementeren. In de aankondiging wordt de ondersteuning voor beschermde inhoud omschreven als de mogelijkheid voor applicaties om bijvoorbeeld rendering uit te voeren met resources waar ze niet bij kunnen of die ze niet kunnen kopiëren.

Kortom: binnenkort weer spellen die keurig legaal gekocht zijn maar niet meer werken? Wanneer gaat deze zinloze ellende eens ophouden?

[DarkJack]

nee, dit is meer om technologïen zoals HDCP binnen een rendering engine te supporteren

denk aan dit scenario: je wil Netflix aanbieden binnen een AR of VR game. Netflix vereist bepaalde technologiën om te verhinderen dat je zomaar de content ript en kopiëert uit de framebuffer. Door dergelijke functionaliteit in Vulkan aan te bieden, kunnen ze een dergelijk scenario dus faciliteren.

[t link]

Het is ook niet alsof HDCP in een jaar of zelfs maanden gestript wordt systematisch vooral leuk als ze dan vervolgens iets als HDCP 2.2 flikken bij consumenten, nu moet ik een HDCP stripper gaan kopen om mijn legaal verkregen content fatsoenlijk te kunnen weergeven.

[SG]

HDCP werkt alleen op beshermt content.
Zo heb ik een HDMI non HDCP splitter dan komt protected video streams niet door alleen geluid.
Maar youtube is geen probleem.
Dus eigen gemaakte content zal geen probleem zijn.

[t link]

Dat weet ik, maar dat zeg ik ook niet. als ik een home cinema set heb met hdmi 2.0 (wantja waarom zouden we zoiets standaard maken) die toevallig geen hdcp 2.2 ondersteund wat je nergens kan vinden op de doos of website kan ik niet mijn 4k bluray speler daardoor loopen waardoor ik een soort mesh netwerk van hdmi krijg ipv een enkel aanknooppunt. nu gaat er een hdmi vanuit de bluray speler naar de tv en naar de home cinema set puur voor audio, heb ik opeens drie afstandsbedieningen waarmee ik moet kloten ipv 1.

[GoT.Typhoon]

Foutje.

[Reactie gewijzigd door GoT.Typhoon op 22 juli 2024 23:08]

[lonaowna]

Nee, High-bandwidth Digital Content Protection aka HDCP.

[dcm360]

DHCP deelt netwerkadressen uit (onder andere), HDCP beveiligt datastromen over videokabels.

[Verwijderd]

Je kunt het ook zo zien dat het een security feature is. Intel Spectre / Meltdown doet hetzelfde.

[The Milkman]

Kan het zijn dat er 1 zinnetje mist, wat kort zegt wat Khronos eigenlijk is?

[ATS]

Khronos is, heel in het kort, de organisatie die de standarisering van OpenGL en Vulcan overziet, al vallen er veel meer standaarden onder hun paraplu.

De meeste grote stakeholders in de industrie zijn lid.

[Reactie gewijzigd door ATS op 22 juli 2024 23:08]

[84hannes]

Kan het zijn dat er 1 zinnetje mist, wat kort zegt wat Khronos eigenlijk is?

Ik denk dat je gelijk hebt. Ik zie dat je nog geen topic hebt aangemaakt in het feedback forum, waarom niet?

edit:
kan iemand een keer uitleggen waarom het verboden is te vertellen hoe feedback op tweakers werkt?

[Reactie gewijzigd door 84hannes op 22 juli 2024 23:08]

[The Milkman]

Dank voor de tip Dat vergeet ik dan weer vaak...

[84hannes]

Graag gedaan (al wordt de tip gezien de moderaties niet zo gewaardeerd). De auteur heeft het inmiddels aangepast.

[HollowGamer]

NVIDIA heeft Vulkan 1.1 drivers uitgebracht: https://developer.nvidia.com/vulkan-driver
Al begrijp ik even niet waarom dit in de oude branch is i.p.v. de 391 serie.

[rbr320]

Dat was bij het 1.0 gaan van de Vulkan specificatie ook het geval. Toen kwam Nvidia met driverondersteuning in de 355 branch, terwijl er op dat moment al een veel nieuwere driver beschikbaar was. Waarschijnlijk komt dit doordat Nvidia (en vermoedelijk ook AMD en Intel) al veel eerder toegang heeft gekregen tot drafts van de specificatie, zodat ze alvast aan ondersteuning in hun drivers konden werken. Dat doen ze dan logischerwijs in de op dat moment actuele branch. Zodra de code daar stabiel is wordt het zeer waarschijnlijk snel voorwaards geport naar de nieuwste drivers zoals dat ook met Vulkan 1.0 ondersteuning is gebeurd.

[SG]

Nou gezien de twimtbp en vervolg beleid is de reden meer welke API de "partner" studio gebruiken en game industrie de defacto standaard is waar de high profile big producties van gebruik maken. En games die vooral ook gebenched worden bepaald waar de focus ligt.
Ook is belangrijk om API te gebruiken die al de belangrijke features bied.
En Vulkan liep in begin wat achter op DX12.
De reden dat er eerst stap naar DX12 werd gemaakt en later Vulkan support bij bepaalde licenceerbare engines ook opdook.

[Gekke Jantje]

Dit is wel een beetje een samenzwering theorie, Nvidia zal echt niet bepalen welke API de ontwikkelaars moeten gaan gebruiken, daar is ook 0 bewijs oer te vinden.

[SG]

Het punt is dat nV niet miljoen investeerd in wat popie is bij kleine low profile projecten. Maar grote kaskrakers mijden.
Maar grote titels met of zonder gameworks die bepalen waar de driver team resources en game exe herkenning op los gelaten wordt.

Dus als de API die bij top games meeste toegepast wordt zal driver preoriteit krijgen. En verre tweede positie krijgt uiteraard lagere preoriteit.
Bij AMD is erger zij hebben de resources niet dus zijn de preoriteiten drastischer.

[2green]

Blijkbaar is een Vulkan Desktop vanaf deze versie ook mogelijk gemaakt.

Met deze Vulkan release wijzen de ontwikkelaars op de mogelijkheid van een Pure Wayland Compositor. Zal vast niet binnenkort verschijnen... lijkt me enorm veel werk en draait dan alleen op moderne gpu's.

Bron

[Reactie gewijzigd door 2green op 22 juli 2024 23:08]

[NiLSPACE]

Het is geen tool maar een API zoals DirectX of OpenGL.

[HollowGamer]

Heb je wel een idee waarom Vulkan belangrijk is/gaat worden?

Het zorgt namelijk voor een crossplatform/open API i.p.v. DirectX die juist helemaal het tegenovergestelde is. Verder is het de bedoeling dat je GPU met zo min mogelijk tussenlagen wordt aangesproken, dus uiteindelijk zal dit (nog) betere prestaties moeten opleveren. Met OpenGL is het niet gelukt, maar ik hoop dat dit eindelijk de weg vrijmaakt om ook op Linux (of elk ander platform) een spel/app gewoon de GPU native kan aanspreken.

[SG]

Valt mee studio die games in beperkte scope maken gebruiken licenceerbare engine.
En die engines worden onderhouden door engine tech met hoge kennis van elke relevante API.
Waar je dan als dev via engine uitbkan kiezen. Crossplatform is dan licenceerbare engine feature waar hoop werk en zorgen al uit handen zijn van hardware OS abstractie laag.

Voor die dev die eigen engine bouwen hebben wel volledig met APi te maken voor hun is belangrijk implementatie detail. Maar engine is veel meer dan renderbackend dus in praktijk zorgt producer dat er voor planning en personeel voldoende kennis in team komt voor details van implementatie voor engine team goed uit te kunnen werken. Kleinere studio met beperkte funding focusen zich liever op een platform en pakken dan de volgende. Crossplatform houd ook in per platform een gedeelde productie maar wel eigen Q&A traject. En waar mogelijk door afwijkende HID of features ook aangepast design.
Wat dus inhoud API is klein deel van werk port is buiten APi als goed gedaan moet worden ook kostbaar en veel meer werk dan API alleen.
Bij hele kleine projecten is API werk mischien wel groter maar in zeer grote producties is wat andere 100 van 105 team doen veel belangrijker. En zijn de productie tools voor efficient produceren en goede content pipeline en datadriven engine veel belangrijker.

Een top producer maakt zich meer zorgen voor planning van 99% vele andere zaken in productie dan API waar fan hater zich druk om maken. Maar in productie van 100mil $ een belangrijk doch klein implementatie detail is wat relevant is voor enkele team members. En vaak in geval van licenceerbare engine al deels bepaald is.

Meeste dev richten zich op produceren van game en zijn liever bezig met game mechanics dan hardware abstractie dus voorkeur voor licenceerbare engine met daarbij hogere kevel managed programmeertaal
Zorgt voor betere time to market en daar is API bepaald door engine keuze. Waar je binnen engine ook nog keuze hebt.

[dmantione]

Vaak is het een kosten-/batenafweging om iets wel of niet op een platform uit te brengen. Crossplatformengines als Unity hebben de kosten de afgelopen jaren dramatisch verlaagd om spellen multiplatform uit te brengen en zijn wellicht wel de belangrijkste component. Zo'n doet zijn best om de onderliggende software van de programmeur af te schermen, maar is daar natuurlijk niet perfect in. Compatibilitieskwesties, bugs en de juiste prestaties zorgt dat er toch nog energie gestoken moet worden in het uitbrengen van een spel op een ander platform. Het is op dat punt dat Vulkan zijn steentje bijdraagt in het verder velagen van de kosten: Minder verschillen in API zorgt automatisch voor minder compatibilitieskwesties, bugs en prestatieproblemen.

Daarom denk ik dat Vulkan ook voor multiplatformengines zeer beduidend is.