Add SPIR-V codegen

[antiagainst]

We are Google engineers working on Vulkan/SPIR-V developer tools. We would like to extend DirectXShaderCompiler so it can compile HLSL into SPIR-V for Vulkan.

HLSL is the prevalent shading language nowadays and DirectXShaderCompiler is the reference compiler for HLSL. Therefore we believe this effort will benefit the general graphics ecosystem.

The general approach is to directly translate frontend AST into SPIR-V words. Main components involved include:

• SPIR-V Builder classes
• SPIR-V codegen from AST
• Parser support for key Vulkan concepts
  • E.g., descriptor bindings and specialization constants
• AST semantic analysis for Vulkan
  • E.g., checking constraints and possibly transforming the AST to map to Vulkan semantics
• Associated tests

This does not reflect the order of implementation. Currently we have the basic SPIR-V infrastructure (SPIR-V builder classes, ASTFrontendAction, and command line integration) ready and will upstream them soon.

For more details about the logistics and design choices, please see docs/SPIR-V.rst.

cc @dneto0 @ehsannas @jfroy

[oscarbg]

Very nice effort..
and may be even better for shader translation quality to what I had in mind..
anyway when I was asking for DXIL->SPIRV translation specifically I was thinking for some future Wine support of DX12 games using SM6.0 features with precompiled DXIL code so a potential D3D12 over Vulkan translator would require translating DXIL code to SPIR-V..
do you think still some of you effort will intersect with this use case?
thanks..

[jfroy]

@oscarbg We elaborate on the details in docs/SPIR-V.rst (see PR #215), but the tl;dr is we do not believe it would be possible to emit valid Vulkan SPIR-V from optimized DXIL, hence our AST approach.

[thewilsonator]

@oscarbg Well if/when I finish my SPIRV backend for LLVM it should be possible to go
HLSL->DXIL->(Reverse translate) LLVM IR->SPIRV, but I cannot guarantee any timeline for that.

That would also require "transplanting" the DX stuff from this repo into my LLVM (or trunk when I get it into upstream).

[oscarbg]

@thewilsonator I thought that Khronos already provided a bidirectional SPIRV<->LLVM translator but seems only has OpenCL SPIRV support..
so big thanks for your effort in adding Vulkan support.. hope Khronos will accept your changes in her Project.. or not, as also seems you are adding on top of an up-to-date LLVM 5.0 branch, right?
Not clear to me if you plan on working on the "reverse translate" from DXIL to LLVM IR.. or expect others to work on it?
thanks..

[thewilsonator]

@oscarbg yes the Khronos provided bidirectional SPIRV<->LLVM translator only supports OpenCL.

My efforts are to make adding Vulkan support easier as part of moving to a TableGen architecture. I have no current plans to add Vulkan support, but if, as I hope, I get sponsored to work on this then I may, if there is enough demand from the D community, but my priority is still OpenCL support. Of course if anyone wants to take the reigns I am more than happy to help them learn the ropes once I get the codebase in to a somewhat respectable state.

My work is indeed destined (hopefully) for LLVM master as

1. they would only accept code targeting up to date, and
2. it makes testing downstream projects much easier if the SPIRV backend is part of stock LLVM, even if it is the bleeding edge.

About reverse translation from DXIL to LLVM IR: I assumed that MS would already have that builtin, because (at least for Khronos' SPIRV-LLVM) the whole point of reverse translation is so that hardware vendors that already have an LLVM backend can change a few intrinsics and the target and then feed it through their standard backend pipeline.
If it does not exist I certainly have no desire to work on it.

[oscarbg]

thanks for details @thewilsonator!
hope you can work on Vulkan eventually..
I haven't asked Microsoft guys if they are interested in adding DXIL->LLVM IR support..
so let's asks it: it's Microsoft interested in open sourcing a DXIL->LLVM IR translator?
also ask it on:
#68

[thewilsonator]

I wouldn't hold your breath. I won't start sponsored work until halfway though this year and my priority is compute.

[antiagainst]

We consider the SPIR-V CodeGen as mature-ish right now. You can find a summary of HLSL and Vulkan feature coverages in the Shader Toolchain: HLSL for Vulkan slides I presented on April 30th Montreal Vulkan Developer's Day. I'll close this. But yes, we'll continue improving SPIR-V CodeGen and adding new features for sure. ;-P