3 suggestions for your project.. about dxvk HOT 2 CLOSED

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.

from dxvk.

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.

from dxvk.