Vulkan-gränssnittet får stöd för ray tracing

Permalänk
Cylon

Vulkan-gränssnittet får stöd för ray tracing

När Khronos Group standardiserar ray tracing i gränssnittet Vulkan får utvecklare ett alternativ till DirectX Raytracing.

Läs hela artikeln här

Permalänk
Medlem

trevligt 👍🙂

Permalänk
Medlem

Låter lovande

Permalänk
Datavetare

Från artikeln

"Specifikationen stöder också översättning av Microsofts shaderspråk HLSL, vilket ska göra det möjligt att konvertera DXR-anrop till Vulkan-motsvarigheten."

Inget fel där, vill bara trycka på att det inte handlar om någon emulering eller så. En sak man lärt sig den hårda vägen i OpenGL, OpenCL och DirectX var detta: att skriva en specifikation där indata till HW-drivare är kod designad för att fungera som ett någorlunda rimligt medium mellan människa (programmerare) och HW (GPUn) är i praktiken en omöjligt uppgift, det lämnade alldeles för mycket rum för tolkning och man har visat exempel där ett program inte kan sägas bryta mot specifikationen samtidigt som det ändå inte fungerar på en HW/driver kombo som inte heller kan sägas bryta mot specifikationen.

Man sneglade då på GCC och LLVM projekten, båda dessa hade insett fördelarna med att definiera en "virtuell" maskinkod. Man delar sedan in systemet i en "front-end" och en "back-end".

Uppgiften för "font-end" är att ta ett programspråk, C, C++, Rust, Swift, HLSL, GLSL eller vad det nu må vara och oavsett vilken HW man tänker köra på i slutändan spottar man ur sig den virtuella maskinkoden. Så oavsett indata har man nu ett gemensamt mellanformat. Självklart finns samma utrymme för missar i tolkning av programkod här som innan, fördelen är nu att det räcker med en implementation. HLSL front-end tillverkas av Microsoft, GLSL av Khronos etc.

Det varje HW-tillverkare nu behöver göra är översätta den virtuella maskinkoden till ett format för "sin" HW, det är uppgiften för "back-end". Att tolka den virtuella maskinkoden är långt mindre tvetydig än att direkt tolka programkod, det finns rätt mycket erfarenhet av att designa och tolka olika instruktionsuppsättningar.

Tyvärr är inte allt rosor här. Finns ett par olika virtuella maskinkoder, LLVM använder LLVM-IR, Khronos använder SPIR-V både i Vulkan och även OpenCL 2.1 och senare, Microsoft använder DXIL i direct X. Behövs olika front-ends då det är olika mellanformat, men då alla dessa bygger på LLVM kan de ändå utnyttja vissa delar från varandra. Är det som bilden visar med "front-end parsing and validation" och ut kommer LLVMs representation av ett abstract syntax tree (AST).

Så när Vulkan använder sig av HLSL (shader språket i DirectX) är det inte bara begränsat till ray-tracing, man kompilerar helt enkelt shaders med en kompilator som tar HLSL och i stället för att spotta ur sig DXIL spottar den ur sig SPIR-V. Vulkan back-end bryr sig inte om hur SPIR-V genererats, bara den uppfyller specifikationen är det "native" stöd utan översättning!

Permalänk
Medlem

Vilka är det största/vanligaste spelen som använder vulkan idag?

Permalänk
Medlem

När ray tracing kommer till spelet DCS blir det en en ny 20+ kkr dator. Så jag har gott om tid att spara pengar till det

Permalänk
Medlem
Skrivet av KorvMos:

Vilka är det största/vanligaste spelen som använder vulkan idag?

Läste på familjeliv att det var ms röj.
Kan dock inte med säkerhet bekräfta källan.

Permalänk
Medlem
Skrivet av Tazhaul:

Läste på familjeliv att det var ms röj.
Kan dock inte med säkerhet bekräfta källan.

Tror tronen skiftat till loadrunner senaste tiden, men lite osäker... kanske bara var på motorola-macar?

Permalänk
Medlem

Ser fram emot jämförelser mellan Vulkan och DX12 med raytracing.

Vem vet de kanske har en del innovativa optimeringar i Vulkan Raytracing (VulkanR? Vulkan RT? Typ som man säger DXR tänker jag) som pressar Microsoft att göra liknande optimeringar. Vi vet ju egentligen bara i dagsläget att raytracing i realtid är oerhört krävande, vi har inte riktigt kunnat göra direkta jämförelser mellan olika implementationer i samma spel för att se om det kanske kan göras bättre på ett eller annat vis.

Permalänk
Medlem
Skrivet av KorvMos:

Vilka är det största/vanligaste spelen som använder vulkan idag?

Första jag kommer att tänka på är senaste Doom, men är inte helt säker.

Sen hur är det med Unreal och Unity motorn?

Permalänk
Medlem
Skrivet av KorvMos:

Vilka är det största/vanligaste spelen som använder vulkan idag?

Red dead redemption 2 använder både DX12 och Vulkan.

Permalänk
Chefredaktör 🕹
Skrivet av KorvMos:

Vilka är det största/vanligaste spelen som använder vulkan idag?

Doom, Wolfenstein och Red Dead Redemption är väl några av bjässarna i alla fall
Många spel som har stöd för Vulkan har ju dock också stöd för DirectX.

Finns en lista här:
https://www.pcgamingwiki.com/wiki/List_of_Vulkan_games

Några av titlarna där är felaktiga, några är typ fan-patchar osv ser det dock ut som. Men de större moderna spelen som listas stämmer.

Permalänk
Raderar framsidor
Skrivet av KorvMos:

Vilka är det största/vanligaste spelen som använder vulkan idag?

Valve gillar Vulkan och erbjuder det i flera spel som använder Source 2.

Half-Life: Alyx och Dota 2 är väl de två största.

Permalänk
Medlem
Skrivet av Yoshman:

Från artikeln

"Specifikationen stöder också översättning av Microsofts shaderspråk HLSL, vilket ska göra det möjligt att konvertera DXR-anrop till Vulkan-motsvarigheten."

Inget fel där, vill bara trycka på att det inte handlar om någon emulering eller så. En sak man lärt sig den hårda vägen i OpenGL, OpenCL och DirectX var detta: att skriva en specifikation där indata till HW-drivare är kod designad för att fungera som ett någorlunda rimligt medium mellan människa (programmerare) och HW (GPUn) är i praktiken en omöjligt uppgift, det lämnade alldeles för mycket rum för tolkning och man har visat exempel där ett program inte kan sägas bryta mot specifikationen samtidigt som det ändå inte fungerar på en HW/driver kombo som inte heller kan sägas bryta mot specifikationen.

Man sneglade då på GCC och LLVM projekten, båda dessa hade insett fördelarna med att definiera en "virtuell" maskinkod. Man delar sedan in systemet i en "front-end" och en "back-end".

Uppgiften för "font-end" är att ta ett programspråk, C, C++, Rust, Swift, HLSL, GLSL eller vad det nu må vara och oavsett vilken HW man tänker köra på i slutändan spottar man ur sig den virtuella maskinkoden. Så oavsett indata har man nu ett gemensamt mellanformat. Självklart finns samma utrymme för missar i tolkning av programkod här som innan, fördelen är nu att det räcker med en implementation. HLSL front-end tillverkas av Microsoft, GLSL av Khronos etc.

Det varje HW-tillverkare nu behöver göra är översätta den virtuella maskinkoden till ett format för "sin" HW, det är uppgiften för "back-end". Att tolka den virtuella maskinkoden är långt mindre tvetydig än att direkt tolka programkod, det finns rätt mycket erfarenhet av att designa och tolka olika instruktionsuppsättningar.

Tyvärr är inte allt rosor här. Finns ett par olika virtuella maskinkoder, LLVM använder LLVM-IR, Khronos använder SPIR-V både i Vulkan och även OpenCL 2.1 och senare, Microsoft använder DXIL i direct X. Behövs olika front-ends då det är olika mellanformat, men då alla dessa bygger på LLVM kan de ändå utnyttja vissa delar från varandra. Är det som bilden visar med "front-end parsing and validation" och ut kommer LLVMs representation av ett abstract syntax tree (AST).

https://cdn.sweclockers.com/artikel/bild/89688?l=eyJyZXNvdXJjZSI6IlwvYXJ0aWtlbFwvYmlsZFwvODk2ODgiLCJmaWx0ZXJzIjpbInQ9YXJ0aWNsZUZ1bGwiXSwicGFyYW1zIjp7ImNhY2hlQnVzdGVyIjoiMjAyMDA0MDgifSwia2V5IjoiZDRhNGNmYWIzYzkzZjQxMjE0ZmE5YTA1NzAyOWIwNDkifQ%3D%3D

Så när Vulkan använder sig av HLSL (shader språket i DirectX) är det inte bara begränsat till ray-tracing, man kompilerar helt enkelt shaders med en kompilator som tar HLSL och i stället för att spotta ur sig DXIL spottar den ur sig SPIR-V. Vulkan back-end bryr sig inte om hur SPIR-V genererats, bara den uppfyller specifikationen är det "native" stöd utan översättning!

Fattar inget 😜

Permalänk
Medlem
Skrivet av KorvMos:

Vilka är det största/vanligaste spelen som använder vulkan idag?

Path of Exile kan köra Vulkan.

Permalänk
Medlem
Skrivet av gh0glund:

Valve gillar Vulkan och erbjuder det i flera spel som använder Source 2.

Half-Life: Alyx och Dota 2 är väl de två största.

Kan även nämna att Valve är med i Vulkan Ray tracing Task SubGroup. Så de var med och tog fram denna specifikation.

Permalänk
Medlem
Skrivet av KorvMos:

Vilka är det största/vanligaste spelen som använder vulkan idag?

En del har svarat på det tidigare. Fyller på med en kommentar angående det.

Vulkan används av Google, och finns både i Android och i deras streamingtjänst Stadia. Spel på Stadia körs i Linux med Vulkan. Spel som finns på både Windows och Stadia kanske vore enklast att bara använda Vulkan. Men om spelet eller motorn redan kör med DX12 på Windows sen tidigare är det kanske enklare för utvecklaren att ha två spår istället.

Permalänk
Medlem

Får hoppas på Ray Tracing ökning i FPS.

Kör det fortfarande inte i ett enda sple med det igång för prestandan är så himla låg.

Dock finns ju DLSS Men DLSS ger inte i samma FPS kurva upp som att köra med RT och DLSS avstängt.

Permalänk
Medlem
Skrivet av Yoshman:

Från artikeln

"Specifikationen stöder också översättning av Microsofts shaderspråk HLSL, vilket ska göra det möjligt att konvertera DXR-anrop till Vulkan-motsvarigheten."

Inget fel där, vill bara trycka på att det inte handlar om någon emulering eller så. En sak man lärt sig den hårda vägen i OpenGL, OpenCL och DirectX var detta: att skriva en specifikation där indata till HW-drivare är kod designad för att fungera som ett någorlunda rimligt medium mellan människa (programmerare) och HW (GPUn) är i praktiken en omöjligt uppgift, det lämnade alldeles för mycket rum för tolkning och man har visat exempel där ett program inte kan sägas bryta mot specifikationen samtidigt som det ändå inte fungerar på en HW/driver kombo som inte heller kan sägas bryta mot specifikationen.

Man sneglade då på GCC och LLVM projekten, båda dessa hade insett fördelarna med att definiera en "virtuell" maskinkod. Man delar sedan in systemet i en "front-end" och en "back-end".

Uppgiften för "font-end" är att ta ett programspråk, C, C++, Rust, Swift, HLSL, GLSL eller vad det nu må vara och oavsett vilken HW man tänker köra på i slutändan spottar man ur sig den virtuella maskinkoden. Så oavsett indata har man nu ett gemensamt mellanformat. Självklart finns samma utrymme för missar i tolkning av programkod här som innan, fördelen är nu att det räcker med en implementation. HLSL front-end tillverkas av Microsoft, GLSL av Khronos etc.

Det varje HW-tillverkare nu behöver göra är översätta den virtuella maskinkoden till ett format för "sin" HW, det är uppgiften för "back-end". Att tolka den virtuella maskinkoden är långt mindre tvetydig än att direkt tolka programkod, det finns rätt mycket erfarenhet av att designa och tolka olika instruktionsuppsättningar.

Tyvärr är inte allt rosor här. Finns ett par olika virtuella maskinkoder, LLVM använder LLVM-IR, Khronos använder SPIR-V både i Vulkan och även OpenCL 2.1 och senare, Microsoft använder DXIL i direct X. Behövs olika front-ends då det är olika mellanformat, men då alla dessa bygger på LLVM kan de ändå utnyttja vissa delar från varandra. Är det som bilden visar med "front-end parsing and validation" och ut kommer LLVMs representation av ett abstract syntax tree (AST).

https://cdn.sweclockers.com/artikel/bild/89688?l=eyJyZXNvdXJjZSI6IlwvYXJ0aWtlbFwvYmlsZFwvODk2ODgiLCJmaWx0ZXJzIjpbInQ9YXJ0aWNsZUZ1bGwiXSwicGFyYW1zIjp7ImNhY2hlQnVzdGVyIjoiMjAyMDA0MDgifSwia2V5IjoiZDRhNGNmYWIzYzkzZjQxMjE0ZmE5YTA1NzAyOWIwNDkifQ%3D%3D

Så när Vulkan använder sig av HLSL (shader språket i DirectX) är det inte bara begränsat till ray-tracing, man kompilerar helt enkelt shaders med en kompilator som tar HLSL och i stället för att spotta ur sig DXIL spottar den ur sig SPIR-V. Vulkan back-end bryr sig inte om hur SPIR-V genererats, bara den uppfyller specifikationen är det "native" stöd utan översättning!

Tolkar jag dig rätt eller har de i princip skapat en kompilator (iaf de flesta stegen förutom just det sista steget till maskinkod) för dx12 kod till vulkan-binärer. Är bara bekant med processorkompilatorer men kan man likna den "virtuella maskinkoden" du pratar om med de instruktionsset vi har på processorsidan, x86, PowerPC, RISC, arm osv? Förstår att det blir annorlunda rent tekniskt eftersom grafikkort brukar stödja flera instruktionsset och är designade på helt olika sätt men om man tänker lite mer vad det innebär i praktiken?

Permalänk
Medlem
Skrivet av KorvMos:

Vilka är det största/vanligaste spelen som använder vulkan idag?

RDR2, Doom är ett par jag kommer på såhär på rak arm.

Permalänk
Medlem
Citat:

...och Vulkan. Det sistnämnda är det modernare gränssnittet som ger utvecklare tillgång till mer hårdvarunära utveckling i stil med vad Microsoft introducerade med DirectX 12

Var det inte AMD Mantle som introducerade det? DX12 populariserade det sen iom att DX är så utbrett. Och Vulkan är väl egentligen Mantle 2.0 eller vad man ska säga? Rätta mig gärna om jag har fel

Men hur kommer det sig sen att DX varit två år före på att implementera raytracing i realtid? Har Vulkan-snubbarna suttit och sovit? 😊

Permalänk
Medlem

Glöm inte att "Ashes of the Benchmark" kan köra en hel drös APIer, bland annat Vulkan.

Permalänk
Medlem
Skrivet av Starric:

Var det inte AMD Mantle som introducerade det? DX12 populariserade det sen iom att DX är så utbrett. Och Vulkan är väl egentligen Mantle 2.0 eller vad man ska säga? Rätta mig gärna om jag har fel

Men hur kommer det sig sen att DX varit två år före på att implementera raytracing i realtid? Har Vulkan-snubbarna suttit och sovit? 😊

Vulkan har haft Nvidia-specifik raytracing sedan länge. Det nya API:et är för alla tillverkare, så det passar bra att det kommer precis när AMD nyss fått stöd.

Permalänk
Datavetare
Skrivet av Starric:

Var det inte AMD Mantle som introducerade det? DX12 populariserade det sen iom att DX är så utbrett. Och Vulkan är väl egentligen Mantle 2.0 eller vad man ska säga? Rätta mig gärna om jag har fel

Men hur kommer det sig sen att DX varit två år före på att implementera raytracing i realtid? Har Vulkan-snubbarna suttit och sovit? 😊

Vulkan är rätt mycket Mantle 2.0, det man primärt jobbade med inför Vulkan 1.0 var att banka ur de delar av Mantle som var väl hårt bundna till GCN. Som exempel har Vulkan, till skillnad från både DX12 och Mantle, explicit stöd för tile-based-deferred-rendering som är en teknik i princip alla GPUer för mobiler använder.

Lite oklart hur mycket DX12 egentligen kan ha påverkats av Mantle då utvecklingen av DX12 måste ha skett rätt mycket parallellt med Mantle. Parallellt med DX12 och Mantle utvecklades även Apples Metal.

Så här ett par år senare kan man konstatera att själva "lågnivå" delen i Vulkan/DX12 är ett stort misstag, Apple har med Metal visat att det är helt onödigt och alla de egenskaper man primärt ville åt går att uppnå även med högre abstraktionsnivå.

Att rendera en enda triangel i Vulkans C/C++ API är helt hjärndött komplicerat jämfört med motsvarande i Metal. Lika så krävs enormt mycket boilerplate i Vulkan för en "hello world" compute shader. Därför spännande att följa Vulkano, det är en "Vulkan bindning" för programspråket Rust där man lagt abstraktionsnivån betydligt närmare Metal.

Är så mycket enklare att komma igång med Vulkan via Vulkano än det är att göra det via det officiella C/C++ APIet. Förhoppningsvis filas det på Vulkan 2.0 och DX13, för är övertygad att en stor orsak till att övergången till Vulkan/DX12 går så löjligt långsamt är för att det är onödigt komplicerat.

Permalänk
Chefredaktör 🕹
Skrivet av dlq84:

Vulkan har haft Nvidia-specifik raytracing sedan länge. Det nya API:et är för alla tillverkare, så det passar bra att det kommer precis när AMD nyss fått stöd.

Kan tilläggas att det funnits provisional stöd för generiska RT extensions i Vulkan sedan ett tag tillbaka. Det som hände nu var mer att det gick ur "beta"-stadiet.

Vad jag vill ha sagt med det är helt enkelt att spelutvecklare, AMD, Intel mfl. har kunnat jobba på sina generiska RT-implementationer sedan cirka ett år tillbaka. Så det är inte som om det blir tillgängligt och de först kan börja mixtra med det idag. Däremot har man inte (mig veterligen) skeppat någon slutanvändarmjukvara som använt det (helt enkelt eftersom det varit smidigare att använda Nvidias extention då det ändå var den enda hårdvaran som fanns med stöd för RT-)

Permalänk
Datavetare
Skrivet av Zpiritual:

Tolkar jag dig rätt eller har de i princip skapat en kompilator (iaf de flesta stegen förutom just det sista steget till maskinkod) för dx12 kod till vulkan-binärer. Är bara bekant med processorkompilatorer men kan man likna den "virtuella maskinkoden" du pratar om med de instruktionsset vi har på processorsidan, x86, PowerPC, RISC, arm osv? Förstår att det blir annorlunda rent tekniskt eftersom grafikkort brukar stödja flera instruktionsset och är designade på helt olika sätt men om man tänker lite mer vad det innebär i praktiken?

Just det. Här har du ett väldigt enkelt exempel från LLVM.

Koden till vänster, den kompileras till det i kolumn 2 (LLVM-IR d.v.s. en virtuell maskinkod som LLVM använder för CPUer), som sedan kan översättas till endera x86_64 (kolumn 3) eller ARM64 (kolumn 4).

Permalänk
Medlem
Skrivet av Yoshman:

Är så mycket enklare att komma igång med Vulkan via Vulkano än det är att göra det via det officiella C/C++ APIet. Förhoppningsvis filas det på Vulkan 2.0 och DX13, för är övertygad att en stor orsak till att övergången till Vulkan/DX12 går så löjligt långsamt är för att det är onödigt komplicerat.

Du menar "gick" inte "går". Spel nuförtiden använder DX12/Vulkan i huvudsak, om det inte är mindre spel som sannolikt kan tänkas köra enklare API eftersom det inte behövs något annat. Inget av de nyare spel jag har installerade kör DX11.

Håller med att DX13/Vulkan X behöver göra det enklare för utvecklarna.

Permalänk
Datavetare
Skrivet av Fulci:

Du menar "gick" inte "går". Spel nuförtiden använder DX12/Vulkan i huvudsak, om det inte är mindre spel som sannolikt kan tänkas köra enklare API eftersom det inte behövs något annat. Inget av de nyare spel jag har installerade kör DX11.

Håller med att DX13/Vulkan X behöver göra det enklare för utvecklarna.

Övergången kanske satt fart nu, de har ju inga val om de vill använda t.ex. DXR då det inte stöds av DX11.

Problemet är att man har aldrig lyckats visa någon relevant prestandafördel i DX12 över DX11 i de fall där DX11 har alla nödvändiga finesser. Att DX12/Vulkan är betydligt mer komplicerat är det ändå rätt mycket konsensus över.

DX12/Vulkan är framtiden, de rättar flera fundamentala problem som DX11/OpenGL har. Men vi har aldrig sett en så här långsam övergång till en ny DX-version, DX12 lanserades sommaren 2015 och har tydligen slagit igenom på bred front 2020. Utan DXR undrar jag om det genomslaget hade hänt, vilket i så fall pekar på att man blev knuffad in i DX12/Vulkan och inte något man själv drogs mot.

Om så är fallet kanske man borde fundera varför, misstänker just att man över-komplicerade saker genom att ta det "low-level" utan att det ger något. "Low-level" och heterogen HW, vilket vi definitivt har på PC, är en usel kombo.

Permalänk
Medlem
Skrivet av KorvMos:

Vilka är det största/vanligaste spelen som använder vulkan idag?

De nya DOOM-spelen skulle jag gissa på.

Permalänk
Medlem
Skrivet av Yoshman:

Från artikeln

"Specifikationen stöder också översättning av Microsofts shaderspråk HLSL, vilket ska göra det möjligt att konvertera DXR-anrop till Vulkan-motsvarigheten."

Inget fel där, vill bara trycka på att det inte handlar om någon emulering eller så. En sak man lärt sig den hårda vägen i OpenGL, OpenCL och DirectX var detta: att skriva en specifikation där indata till HW-drivare är kod designad för att fungera som ett någorlunda rimligt medium mellan människa (programmerare) och HW (GPUn) är i praktiken en omöjligt uppgift, det lämnade alldeles för mycket rum för tolkning och man har visat exempel där ett program inte kan sägas bryta mot specifikationen samtidigt som det ändå inte fungerar på en HW/driver kombo som inte heller kan sägas bryta mot specifikationen.

Man sneglade då på GCC och LLVM projekten, båda dessa hade insett fördelarna med att definiera en "virtuell" maskinkod. Man delar sedan in systemet i en "front-end" och en "back-end".

Uppgiften för "font-end" är att ta ett programspråk, C, C++, Rust, Swift, HLSL, GLSL eller vad det nu må vara och oavsett vilken HW man tänker köra på i slutändan spottar man ur sig den virtuella maskinkoden. Så oavsett indata har man nu ett gemensamt mellanformat. Självklart finns samma utrymme för missar i tolkning av programkod här som innan, fördelen är nu att det räcker med en implementation. HLSL front-end tillverkas av Microsoft, GLSL av Khronos etc.

Det varje HW-tillverkare nu behöver göra är översätta den virtuella maskinkoden till ett format för "sin" HW, det är uppgiften för "back-end". Att tolka den virtuella maskinkoden är långt mindre tvetydig än att direkt tolka programkod, det finns rätt mycket erfarenhet av att designa och tolka olika instruktionsuppsättningar.

Tyvärr är inte allt rosor här. Finns ett par olika virtuella maskinkoder, LLVM använder LLVM-IR, Khronos använder SPIR-V både i Vulkan och även OpenCL 2.1 och senare, Microsoft använder DXIL i direct X. Behövs olika front-ends då det är olika mellanformat, men då alla dessa bygger på LLVM kan de ändå utnyttja vissa delar från varandra. Är det som bilden visar med "front-end parsing and validation" och ut kommer LLVMs representation av ett abstract syntax tree (AST).

https://cdn.sweclockers.com/artikel/bild/89688?l=eyJyZXNvdXJjZSI6IlwvYXJ0aWtlbFwvYmlsZFwvODk2ODgiLCJmaWx0ZXJzIjpbInQ9YXJ0aWNsZUZ1bGwiXSwicGFyYW1zIjp7ImNhY2hlQnVzdGVyIjoiMjAyMDA0MDgifSwia2V5IjoiZDRhNGNmYWIzYzkzZjQxMjE0ZmE5YTA1NzAyOWIwNDkifQ%3D%3D

Så när Vulkan använder sig av HLSL (shader språket i DirectX) är det inte bara begränsat till ray-tracing, man kompilerar helt enkelt shaders med en kompilator som tar HLSL och i stället för att spotta ur sig DXIL spottar den ur sig SPIR-V. Vulkan back-end bryr sig inte om hur SPIR-V genererats, bara den uppfyller specifikationen är det "native" stöd utan översättning!

Att detta är möjligt får man även tacka Microsoft för och deras arbete med att öppna upp de delar som krävs.
Jag hoppas att vi får se ännu bättre lösningar i framtiden med bättre samarbete mellan de olika plattformar som finns.