Stor förändring på gång i DirectX

Uttalas det spir V eller spir fem?

Sett till att versionerna 1 och 2 av SPIR (utan V) släpptes innan (men varken 3 eller 4) (och utan romerska siffror), att det finns en 1.0 version av SPIR-V 1.0, och att SPIR-V är första med Vulkan, gör att jag satsar på det första. Och att jag uttalar det SPIR-V och inte tänker ändra mig.

Standard Portable Intermediate Representation.

V står för Vulkan.

Så det läses knappast som 5.

HMMM.

öppen standard i directX you say
någon mer än jag som eventuellt ser möjligheter att någon smart jäkel kanske reverse engineerar och portar directX till linux i framtiden.

man kan ju alltid hoppas iaf.

Jag tycker vi kallar det "sparv".

VKD3D (DX12) och DXVK (DX11 och äldre) är väl i princip det? Det är översättningslager snarare än portar, men det funkar ju rätt bra i många spel nu för tiden.
Används av Proton m.fl. för spel i Linux.

Varför inte lägga ner DirectX då och börja satsa helt på Vulkan?
Tycker alla spel jag sprungit på som haft stöd för båda så fungerar det alltid bättre i Vulkan, och om dom nu vill satsa på Linux i framtiden så....

För att köra DirectX-applikationer i Linux kommer det även i framtiden att behövas översättningslager som t.ex. Proton. SPIR-V/DXIL handlar om GPU-shaders, DirectX och Vulkan är fortfarande två olika APIer för CPU-sidan.

SPIR-V är väldigt likt hur t.ex. Java-program kompileras till bytekod och C#-program kompileras till CIL-kod, d.v.s. man kompilerar till en “virtuell” instruktionsuppsättning vars primära uppgift är att göra det enkelt/effektivt att i sin tur kunna översättas till den faktiska instruktionsuppsättningen som körs på den enhet som i slutändan vill köra programmet.

Det här är ändå positivt för de som vill använda tekniker som Proton (positivt i bemärkelsen “en felkälla mindre”, potentiellt negativt i: om inte sista spiken i kistan redan är inslagen för “utveckla spel för native Linux” lär detta ge den effekten). Trots att man även framåt måste översätta DirectX till motsvarande Vulkan-anrop slipper man ju kompilera om DXIL till SPIR-V om man vill köra spel på Linux.

För Microsoft lär det också bara finnas fördelar. För dem lär det inte finnas några fördelar alls med DXIL över SPIR-V, tvärtom slipper man ju en kostnad genom att använda SPIR-V.

Positivt också för GPU-tillverkare, de får ett lite enklare jobb om de framåt bara behöver bry sig om SPIR-V -> GPU-specifika instruktioner. Om Microsoft fixar riktigt bra DXIL -> SPIR-V-översättare i Windows skulle man rätt snabbt kunna släppa DXIL-stöd i GPU-drivrutiner utan att dagens spel drabbas.

Bloggen som länkas belyser rätt bra fördelarna för Microsoft

As we look to the future, maintaining a proprietary IR format (even one based on an open-source project) is counter to our commitments to open technologies, so Shader Model 7.0 will adopt SPIR-V as its interchange format. Over the next few years, we will be working to define a SPIR-V environment for Direct3D, and a set of SPIR-V extensions to support all of Direct3D’s current and future shader programming features through SPIR-V. This will allow developers to take better advantage of existing tools and unify the ecosystem around investing in one IR.

In addition to providing a compiler for HLSL to Direct3D’s SPIR-V, we will also be building and providing translation tools to translate SPIR-V to DXIL and DXIL to SPIR-V. Those tools will allow and driver developers to gradually transition and gracefully adapt tooling and drivers.

Finns inget strategiskt i att pusha DXIL för Microsoft del. Positiva är det inte bara är Microsoft som får en kostnadsbesparing, det får även GPU-tillverkarna. Resurser som istället kan läggas på nya coola features.

Sen finns riktigt positiva sekundära effekter. SPIR-V används inte bara av Vulkan idag, det används också som virtuell GPGPU ISA för OpenCL och SyCL (SyCL är Khronos svar på CUDA, används av bl.a. Intel i OneAPI och Arm/Qualcomm för deras GPGPU stöd).

Ett steg i rätt riktigt för att skapa något på GPGPU-sidan som faktiskt kan utmana CUDA. Detta då ett helt gemensam "mellanlager" gör det enklare att skapa stora mängder GPGPU-bibliotek likt vad vi har i t.ex. Java/.NET idag.

Inte ofta man ser detta, men plötsligt händer det! Normalfallet är annars nästan alltid detta