Khronos brengt definitieve specificatie van Vulkan Raytracing-standaard uit

De Khronos Group heeft de definitieve Vulkan Raytracing-specificatie uitgebracht. Deze open standaard kan door ontwikkelaars kosteloos gebruikt worden om raytracing toe te voegen aan Vulkan-games. Medio december volgt daarvoor een software development kit.

De definitieve release staat inmiddels op GitHub. Khronos meldt nu dat Vulkan Raytracing 'vertrouwd zal zijn voor iedereen die DirectX Raytracing heeft gebruikt'. Tegelijkertijd introduceert Khronos enkele nieuwe functies. Zo kan de cpu van een systeem gebruikt worden om raytracing setup-operations uit te voeren, meldt het consortium.

Khronos bracht in maart al vroege versies van de Vulkan-raytracingextensies uit, maar maakte toen niet bekend wanneer de definitieve specificatie uit zou komen. Het consortium deelde toen al wel verschillende details over de extensies. Vulkan Raytracing is een open standaard, die cross-vendor is en 'hardware-agnostisch' werkt. Dat wil zeggen dat de standaard in theorie werkt op videokaarten van alle fabrikanten.

De standaard kan ook op gpu's zonder losse raytracinghardware functioneren, hoewel ondersteuning door fabrikanten moet worden toegevoegd via gpu-drivers. AMD, Intel en Nvidia hebben al toegezegd dat ze Vulkan Raytracing in enige mate gaan ondersteunen. Op termijn moet Vulkan Raytracing zelfs ondersteund worden op mobiele platforms, zo meldt Khronos.

De release-tijdlijn van Vulkan Raytracing. Afbeelding via de Khronos Group

Khronos heeft sinds maart verschillende veranderingen in de specificatie doorgevoerd, waarop het consortium uitgebreid ingaat in zijn aankondigingsblog. Waar de vroege versie van Vulkan Raytracing-uitbreiding bijvoorbeeld bestond uit een enkele extensie, is dit in de uiteindelijke release opgesplitst in drie verschillende extensies. Respectievelijk gaat dat om losse uitbreidingen voor raytracing-queries, -pipelines, en -acceleration. Dit deed het consortium na feedback, waaruit bleek dat 'bepaalde markten' graag raytracing-queries willen ondersteunen zonder pipelines.

Met de uiteindelijke release kunnen ontwikkelaars er dan ook voor kiezen om deze queries- of pipelines-uitbreidingen gezamenlijk of afzonderlijk te ondersteunen. De acceleration-extensie is overigens niet optioneel: "De query- en pipeline-uitbreidingen zijn afhankelijk van de VK_KHR_acceleration_structure-extensie om een gemeenschappelijke basis te bieden voor het beheer van de versnellingsstructuur."

Verder zijn de dependencies voor alle extensies aangepast; Vulkan 1.1 en SPIR-V 1.4 zijn nu vereisten, zo meldt Khronos. Ook worden de versnellingsstructuur en deferred host operations aangepast, en worden er minder ingrijpende wijzigingen gemaakt in de raytracing pipelines en ray queries zelf.

Naast de definitieve specificatie, publiceert Khronos ook een blogpost waarin de implementatie van 'hybrid rendering' wordt besproken, waarbij raytracing in beperkte mate wordt gebruikt, in combinatie met het meer traditionele rasterization. In deze blog wordt Wolfenstein: Youngblood als voorbeeld genoemd. Die game maakt momenteel nog gebruik van een gesloten raytracingstandaard van Nvidia, waarop Vulkan Raytracing is gebaseerd. Het is niet duidelijk of Youngblood op termijn ook ondersteuning krijgt voor de nieuwe, open standaard.

Wolfenstein: Youngblood zonder raytracing (links) en met raytracing. Afbeelding via de Khronos Group

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (19)

Mooi om te zien dat ze ook DXR layeren kunnen over Vulkan. Ik kan me voorstellen dat dat gedaan is om het makkelijk te maken om Windows games onder Linux te draaien met bv DXVK of VKD3D.

Uhm, er wordt niks gewrapt of 'gelayerd'?

Zie de afbeelding in het artikel. Developers hadden feedback dat ze eenvoudig DXR wilden kunnen layeren over Vulkan. Oftewel, makkelijk een API porten naar Vulkan. Wat gebruikt kan worden voor VKD3D, wat Direct3D 12 apps onder Linux icm Wine gebruik laat maken van Vulkan ipv de niet bestaande DirectX support.

Volgens mij raakt menig ontwikkelaar in paniek als je hun software op een niet ondersteund platform gaat draaien, dus lijkt me sterk dat DAT de reden was

Ben wel benieuwd wat er precies bedoelt word met dat ‘layering’ en hoe dat in z’n werk gaat.

[Reactie gewijzigd door Wolfos op 23 november 2020 22:40]

Mooi om te zien dat ze ook gelijk de nadelen aanstippen: een halve reflectie in een vloer omdat het object wat gereflecteerd dient te worden nog niet in beeld is.

Eerlijkheid gebied te zeggen, de officiele Direct X documentatie vernoemd die beperkingen ook:
https://microsoft.github....Specs/d3d/Raytracing.html

NVidia gaat die echter natuurlijk niet noemen in de marketing van hun eigen producten.

Niet een halve reflectie, maar in een hybride opstelling (wat nog wel echt een must is, zie Quake II RTX performance), waar een groot deel van de belichting dus in screen space wordt gedaan, kan je dus niet licht reflecteren wat niet bestaat. Dit is wat ze laten zien in het screenshot, het licht van de bovenste rand valt voor de helft buiten het frame, maar in de reflectie is dit niet het geval en dus krijg je een "halve" reflectie.

Dit is niet een limiet van Vulkan Ray Tracing, maar van hoe de techniek wordt toegepast.

Ik vind het spiegelreflectie "truukje" wel geinig maar ben meer interesseert in het effect van belichting tegen over oppervlakte dus lichtreflectie. Wat nou als je de belichting laat doen door een lichtman van een redelijke hollywoodstudio of een goede (op lichtspel georiënteerde) fotograaf.

Ook vraag ik me af of textures zelf nog wel shadows nodig hebben nu je alles via raytracing kunt belichten inclusief het effect van bitmaps. de selfshaded graphics van Zelda Breath of the wild zijn een mooi voorbeeld van wat dan mogelijk word: zie link.

https://www.youtube.com/watch?v=w4UHrM0LzYo

Het moet naar mijn ogen nog volwassen worden. Ik zie toch echt te vaak HDR beelden met te hoge contrast om te laten zien dat het HDR is, Raytracing met teveel reflectie omdat het Raytracing het zelfde met bloom, motion blur, lensflares, godrays ect... Games die dit beter in balans presenteren hebben bij mij toch echt een voorkeur.

Je bedoeld cel-shading dat is versimpeld gezegd "schilderen op nummer" en heeft niets te maken met de gebruikte verlichting techniek. Je geeft zelf aan dat je overdreven bloom effecten vervelend vind een laat Zelda nu juist sterke bloom effecten hebben.

Ook heeft HDR wederom niets met raytracing te maken of raytracing met de hoeveelheid reflecties. Volgens mij moet je je nog eens in de technieken verdiepen, en heb je nu vooral een voorkeur voor een bepaalde balans in grafische keuzes en niet zo zeer technieken.

Een 'echte gaffer' belicht per shot. Dat kan helaas nooit voor een game want je moet er vrij in rond kunnen lopen. Ik denk oprecht dat de beste belichters voor games, game belichters zijn. En het is niet zo dat er nu niet wordt belicht, alleen baken ze dat nu vaak. Het hele race tracen zal ook een productioneel voordeel hebben. Er hoeven nu minder trucjes te worden uitgehaald om het een bepaalde kwaliteit te halen.
Wel ben ik bang dat dit weer een stap is in de richting dat alle games op elkaar gaan lijken. Het wordt steeds en steeds makkelijker om gewoon de realiteit na te maken, ook met dingen zoals megascans die een hele grote library hebben aan ingescande assets (rotsen, taken, bomen, stenen noem maar op https://quixel.com/megascans/). Op termijn kan ik me voorstellen dat iets gestileerd maken, zoals zelda botw, misschien meer tijd kost dan iets realistisch.

Zou toch wel top zijn als we daar een 2e kaart voor zouden kunnen inzetten. Zijn de mensen die nog crossfire achtige opstellingen hebben ook geholpen....

SLI en crossfire zijn wel een beetje verleden tijd, gezien de teruglopende support. Er schijnen veel frametime issues te zijn met dit soort opstellingen.

Dat klopt ja, maar aangezien er een aantal toffe games zijn die er perfect mee werken is het dus meer de keuze van de ontwerpstudio , en het creëren van draagvlak in het algemeen, om dit voor elkaar te krijgen.
Aan de opstelling "an sich" zal het niet liggen of inmiddels liever gezegd gelegen hebben.

Waar ik in eerste instantie op doelde is, dat er een eventuele 2e kaart mee zou kunnen helpen met het berekenen.
Niet het 1 op 1 of beter gezegd 1 op 2 ( om en om renderen van een frame) overnemen van taken.
Ik dacht meer aan een situatie zoals met de AGEIA physics processing unit (PPU) die voorheen een aantal physics taken op zich nam en zo de rest van het systeem ontlast, maar dat kan natuurlijk ook gewoon een 2e kaart zijn...

Het Wolvenstein voorbeeld zie ik niet direct als bewijs dat deze de officiele Vulkan Raytracing gaat ondersteunen. De officiele Vulkan raytracing ondersteuning is gebaseerd op de Nvidia raytracing extention voor Vulkan, en die Nvidia extention wordt voor Wolvenstein gebruikt. Dus Wolvenstein is nu al een goed voorbeeld (beste praktijk voorbeeld) voor de werking van Vulkan raytracing.

Ik heb de gelinkte blogpost nogmaals gelezen, en ik heb het idee dat ik het overview-gedeelte verkeerd heb gelezen. Ik las daar dat Youngblood is uitgebracht met 'vroege versies van Vulkan Raytracing', maar het is inderdaad aannemelijk dat daarmee gewoon VK_NV-raytracing wordt bedoeld, waarop Vulkan Raytracing (zoals je ook correct opmerkt) is gebaseerd. Ik scherp dit stuk aan

Mooi om te zien dat RT ook naar linux gaat komen!

Ja top, ben ik net een applicatie aan het ontwikkelen met de oudere Nvidia-only extensie..

Dat maakt toch verder niet uit, dat kun je toch afmaken? ... als de applicatie een beetje fatsoenlijk opgezet is, kun je er zo een render path naast zetten.

Nja naast zetten, ik denk dat ik beter een weekendje kan nemen om het te porten. Weinig nut om een oude Nvidia-only versie te blijven ondersteunen.