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

Permalänk
Melding Plague

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

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk
Medlem

trevligt 👍🙂

Visa signatur

In science we trust!

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!

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

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

Visa signatur

Dell S2721DGFA ■ 5800X3D (Noctua NH-U12P) ■ RTX 3070 AORUS Master ■ 16x2 3200 CL16 ■ MSI B450M Mortar Max ■ Samsung EVO 970 1 TB ■ Fractal Design North + Switch OLED

Old: Pentium 4 -> Core 2 Duo E6750 -> i7 2600k -> R7 3700X

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.

Visa signatur

AMD Ryzen 5600x | Asus Strix x570-f gaming | Gigabyte 3070 Eagle OC | Corsair Vengeance RGB PRO 32GB 3600mhz | WD Black SN850 1TB Gen 4

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

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?

Visa signatur

Rota3: Ryzen 5600 - 32GB - Radeon RX 7600 - Kingston NV200 2TB - Fractal Design R3 - EVGA Supernova 750W

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.

Visa signatur

sweclockers prestandaindex

Efter 10 kommer 11.
Efter 99 kommer 100.

Permalänk
Konsolpleb 🕹
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.

Visa signatur

240p är livet

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 😜

Visa signatur

Corsair Obsidian 900D, Intel Core I9 9900k@5ghz/1.270v, Asus Maximus XI Hero, ASUS GeForce RTX 3080 10GB ROG STRIX GAMING OC, G.Skill Trident Z 4x8GB 3600mhz, Corsair RM650i

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.

Visa signatur

i9 11900k ||32GB 4000MHz CL15||ASUS ROG STRIX Z590-E||Noctua NH-D15s
Intel Arc a750 ||Samsung 980 pro|| EVGA Supernova G3 850W
Asus xonar essence STX|| Lian-Li O11 Dynamic XL
Asus VG27AQ 165Hz IPS, Sennheiser HD650, Logitech g502 Hero, fUnc f30r, Vortex TAB90M, Audio-Technicha ATR2500x-USB
Server: x10SL7-F, Xeon E3 1230v3, 32GB Samsung ECC ram, 6x3TB WD RED, FD Node 804.

Permalänk
Medlem
Skrivet av Gustav Höglund:

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.

Visa signatur

MSI X99A GODLIKE GAMING | i7-6950X 4.3GHz | 64GB RAM 3200MHz | RTX 2080

Nintendo Switch | PlayStation 5 | Xbox Series X

Min FZ Profil

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?

Visa signatur

Desktop - Intel i7 6700K | Asus Z170-A | 32 GB Corsair DDR4 | RX 6700 XT w/ Arch Linux
Laptop - Thinkpad X1 Carbon Gen. 4 w/ Arch Linux
NAS - Ryzen Pro 3400G @ 35W | 64GB ECC | 32 TB HDD w/ TrueNAS Core

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? 😊

Visa signatur

Ryzen 7600X - Geforce RTX 4080 - Custom Loop - Samsung 34" Ultra Wide
Intel i7 9700K - Radeon VII

Permalänk
Medlem

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

Visa signatur

Mjölnir: Ryzen 9 3900X | X570-I | Ballistix Sport 32GB | Powercolor RX 5500XT 4GB ITX | Kolink Sattelite
Server: Ryzen 5 1400 | X470-F | Ballistix Sport 24GB | ASUS HD 7790 2GB | Sapphire RX 470 8GB ME | NZXT Switch 810

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.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Konsolpleb 🕹
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-)

Visa signatur

240p är livet

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).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

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.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

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.