Support Vulkan?

[skl131313]

Not sure if Vulkan is currently supported or not, but it seems only OpenCL is?

[yxsamliu]

Currently the translator only supports OpenCL.

[thewilsonator]

After I'm done getting LDC to support OpenCL SPIR-V then if there is sufficient demand (principally within the D community, but other contributors are ofc welcome) I may consider making a fork of llvm off the latest version, updating this (OpenCL SPIR-V) to the latest llvm version and adding a Vulkan backend to it. Possibly also considering trying to integrate Microsoft's recently open-sourced DirectXShaderCompiler, although it's git history will definitely be bjorked. Will wait till development of it has matured a bit.

If I get around to doing that I will be changing a few things: most noticeably using llvm intrinsics for the OpenCL/Vulkan intrinsics rather than "itanium with extensions" C++ mangling, making it far easier to use with other tools.

[keryell]

@thewilsonator: while working on https://github.com/keryell/triSYCL/ I am looking at leveraging http://alphanew.net/index.php?section=alphanew&site=overview&lang=eng&newsID=111
Perhaps you can use it too?

[thewilsonator]

@keryell Well, it doesn't have releases which makes doing CI difficult, see #201. It is also 105 commits behind KhronosGroup/SPIRV-LLVM 3.6.1 and is on LLVM 3.9.0 as opposed to the final release of that series 3.9.1. It also hasn't received any commits for 11 months.

Hence why I am considering doing it myself. Also I will probably put the lib/SPIRV and tools/llvm-spirv and tools/spirv-tool in their own submodules, to keep things separate and easily identifiable. Will do the same for MS's DirectXShaderCompiler.

[dneto0]

Please be aware that the dialect of SPIR-V accepted by Vulkan is significantly different from the dialect accepted by OpenCL. For starters, see the validation rules in the SPIR-V spec for "Shader" vs. "Kernel". Also, check extra restrictions in SPIR-V environment spec in the Vulkan spec: https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/html/vkspec.html#spirvenv

[thewilsonator]

Isn't it just SPIR-V core + Vulkan specific capabilities + Vulkan specific operations (a.k.a. "standard library functions")?

[dneto0]

Yes, but that's a big difference from SPIR-V for OpenCL. You're subtracting out a lot of assumptions made by SPIRV-LLVM assuming it's targeting OpenCL.

Examples:

• In Vulkan all your control flow has to be "structured", with OpLoopMerge and OpSelectionMerge at key points in the control flow graph. If you've lost that original control flow intent from the source language, then you've changed semantics of the program. In OpenCL, you only have to ensure control flow is reducible. That's way simpler to maintain through the compiler flow.

• Storage classes are completely different. Vulkan has about 10 valid storage classes, and OpenCL has 4. Vulkan's set is not a superset of OpenCL's.

• OpenCL uses physical addressing, where all types automatically have a fixed size and alignment. Vulkan requires logical addressing. For objects in storage classes exposed to the host API (e.g. Uniform), layout annotations have to be applied.

• Vulkan's LogicalAddressing model assumes that pointers don't alias unless proven otherwise. OpenCL is like C in that the default is the opposite: pointers are assumed to alias unless proven otherwise.

I urge you to consider all the details first before diving in by writing code.

[keryell]

@thewilsonator: we always appreciate contributions. :-)
On the SPIR-V side, the current LLVM library producing SPIR-V should be updated to a real SPIR-V LLVM back-end, if you are looking to some reorganization ideas...

[thewilsonator]

My reorg ideas are

• make git submodules for lib/spirv,tools/llvm-spirv and spirv-tool, principally to make keeping up with master easier, but also reduce the size if the code base since AFAIK other than include/llvm/Support/SPIRV.h and the relevant build script files nothing else is changed by this project other than the above listed directory.
• make all of the (OpenCL) extensions intrinsics rather than "itanium with extensions" C++ magic mangling ( in llvm.spirv.opencl.*?). This will break clang/anything relying on this. It is of no concern to me, but surely will be for others. Will try to leverage .td tools for this. Should make doing the equivalent for Vulkan easier.
• get a TargetMachine so we can run the dead simple optimisation passes, and fit in with the "normal" backend pipeline.
• move all the OpenCL specific stuff to its own folder, do the same if/when adding vulkan support.

However I won't have any time to do this until August at the earliest.

[thewilsonator]

@dneto0 thanks for the pointers.

Point 1 seems like a good candidate for an intrinsic function to mark the end.

Point 2 doesn't OpenCL have 5? Private, Local, Global, Constant and Generic? Also seems like a good candidate for addrspace qualification. edit: or is this const, volatile, restrict, ???, @?
Found them all valid SPIR-V storage classes are

• UniformConstant:
• Input:
• Uniform:
• Output:
• Workgroup:
• CrossWorkgroup:
• Private:
• Function:
• Generic:
• PushConstant:
• AtomicCounter:
• Image:
  Not obvious which belong to what though.

Point 3 I'm less sure of, but it seems that metadata should work here.

Point 4 It is the host language's problem to annotate everything with noalias.

[dneto0]

@thewilsonator: About storage classes. Yes, OpenCL has 5 (I forgot Generic).

The validity rules are in two places:

1. Inside the SPIR-V spec itself.
2. Each client API that uses SPIR-V specifies additional rules in what it calls an "environment spec".
   https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/html/vkspec.html#spirvenv

There's a matching one for OpenCL.

[thewilsonator]

@keryell I have got a fork of llvm 5.0 with spir and spir64 proper targets (also made a Triple::spirl for logical spirv memory to ease Vulcan support if I get around to it) at https://github.com/thewilsonator/llvm/tree/compute
This is about the last point before I begin to change it use use intrinsics instead of mangled C++, and thus break compatibility with https://github.com/KhronosGroup/SPIR/tree/spirv-1.0 (although the upgrade from 3.6.1 to 5.0 will most definitely have broken things). Let me know if you (or others) want to collaborate on this, more eyes hands and bug reporters are always good.