search

shader-slang / slang

Making it easier to work with shaders
MIT License
2.06k stars 177 forks source link

Difficult to integrate as a cmake submodule #3521

Closed HansKristian-Work closed 2 months ago

HansKristian-Work commented 8 months ago

I'm attempting to integrate slang into https://github.com/Themaister/Granite/tree/slang-integration, but I'm running into several issues.

The ideal way it would work for me is to have a libgranite-compiler.so which statically links the backend. Currently I link in shaderc this way and has worked well. Ideally, I should be able to link in slang statically into that library as well and have them share glslang/SPIRV-Tools, etc, until shaderc use can be sunset (will take a long while).

First problem is that the slang library is forced to be compiled with SHARED. In my fork https://github.com/Themaister/slang, I've tried to rework the build system to fit my needs better. Once I managed to link slang statically, I ran into issues where glslang backend couldn't be found. After some debugging, the problem was that slang-glslang is another shared library which is not built by default when used as a sub-project, it cannot be linked against (MODULE type), and kind of relies on being installed first for things to work. For local dev builds, this doesn't work well.

I removed all the shared library loading and just invoke glslang_compile_1_2 directly instead.

Another thing I had to do is to add various if (NOT TARGET) to external/ where sub-projects are loaded. Some things like vulkan headers, SPIRV-Tools etc are already loaded by Granite itself. glslang seems to require a special fork to work, so I had to do some gymnastics to make shaderc use slang's fork instead.

However, after all of this I'm getting strange assertions and crashes inside Slang::IRSpecContext which I cannot reproduce in a plain build of this repo which probably warrants another issue, but it's possible the integration was botched somehow in a way that is hard to debug.

expipiplus1 commented 8 months ago

I agree that a simplified build is desirable, especially making a robust static build available for cases such as this.

Probably an easy path forward would be to have the build system able to just use the system glslang directly and skip the slang-glslang wrapper. I think that would be more in line with people's expectations for such a project.

HansKristian-Work commented 8 months ago

system glslang directly

Being able to "bring your own submodule" kind of approach would be good though, or at least being able to link it statically.

I see glslang on Arch at least ships a /usr/lib/libglslang.a, so by default using system libs with override being available from the outside would be the ideal approach.

fknfilewalker commented 7 months ago

Maybe recently merged prs: #3578, #3572 could be helpful to you. One allows to turn off individual slang targets via cmake, and the other allows you to build slang as a static lib via cmake.

swoods-nv commented 2 months ago

We've moved to cmake at this point, and have options to fetch SPIRV headers from system directory, so closing this; please reopen if you're having further issues (or open a new bug specific to any new issues).