3 suggestions for your project..

[oscarbg]

Hi,
just some ideas about your project..
note expect #1 other two may be better to investigate once project is more mature..

1. reusing existing open source projects for DXBC->SPIRV translation..
   just a suggestion as you seem to be reimplementing DXBC to SPIRV shader conversion from scratch..
   for me seems a waste of your time (please forgive me if mistaken) and would be better to reuse at least one of these two projects:
   a) Reuse Wine source code : supports DXBC to GLSL and is someway battle tested on modern D3D11 games
   (should then get SPIRV by using Khronos glslang to go GLSL->SPIRV)
   notes: still lacks some byte codes related to shader linking feature, fp64 optional ops, but they aren't massively used.
   PROs:
   *if you end implementing missing opcodes vs Wine then wine can benefit from your work..
   CONs:
   *GLSL output has to be massaged for Vulkan GLSL specific restrictions?
   *Get knowledgeable about Wine code base
   *Wine licenses issues?
   perhaps personally would choose that..
   b) reuse Unity HLSLCC compiler (https://github.com/Unity-Technologies/HLSLcc)
   you will also need glslang using this path..
   CONS:
   *produces "GLSL for Vulkan consumption (as input for Glslang to generate SPIR-V)" so no potential problems like Wine GLSL output from DXBC..
   *altough well tested in Unity shader codebase,perhaps not robust as Wine shader translation
   PRO:
   additionaly supports Metal language output support (supports vert,frg,compute.. Metal tesselation should be coming soon (now that Unity 2018.1 roadmap mentions Metal tesselation support)..
   so if someway later this project gets forked onto DXMetal shader conversion should already be solved someway..

2. Test Macos support using MoltenVK (vulkan to metal translator)..
   (note: this is not testable right now..)
   Wine staging right now supports Vulkan on Linux and with some patches could support could be brought to Macos by linking to MoltenVK Vulkan library..
   then we can see how your project Vulkan code plays with MoltenVK and workaround current MoltenVK limitations and perhaps provide feedback to MoltenVK author from improvements..
   I plan on doing my testing on my way as soon as I get patches for Wine Vulkan Macos working..

3. Windows Visual studio support..
   past week, with minor changes I got your project to compile with Visual studio 2017 some days ago..
   I generated projects using meson flag: --backend vs2017
   then from IDE fixed the issues one by one if I remember the most frequest were missing #include on some files and the hardest one were to modify my Windows SDK d3d11.h and dxgi.h headers to include declspec(exportdll) as needed to match your function implementations of
   D3D11CreateDevice,D3D11CreateDeviceAndSwapChain,CreateDXGIFactory1,CreateDXGIFactory..

just my three cents.. :-) keep up your great work 👍

[doitsujin]

Thanks again for the input.

1. It is true that the shader compiler is the elephant in the room here. I'll have to think about what to do with it. Although using wine's DXBC->GLSL without modifications is not an option, it might be possible to use its frontend and implement a SPIR-V backend that takes the Vulkan peculiarities into account - but then again it would be a lot of work, and the front end is probably the least problematic part.
   I'm a bit reluctant to add more third-party dependencies to the project and give up the direct DXBC->SPIR-V translation at the same time, it is the most elegant and potentially the most robust solution since the translation is for the most part rather straight-forward, but it obviously requires a lot work and a lot of testing.

2. No objections if someone is willing to maintain it, at least when the project has matured. Right now I don't think it's worth the effort as there will be too many potentially breaking changes in short periods of time.

3. Nice to hear that you actually got it to compile. I'm more than willing to officially support VS2017 and Windows at this point as it can help development (particularly with testing against native Windows Dx11), but I haven't managed to compile it myself yet. Was there anything else you had to set up besides fixing the code?
   As for the dllexport problem, that can be solved by renaming the functions in the code and providing a DEF file to export them with the proper symbol names.

[doitsujin]

Closing this to clean up a little. At this point I don't think there is a reason to switch to a different shader compiler. As for Visual Studio and Mac support, feel free to open dedicated issues for those if interested.