SPIRV-Cross VS shaderc

There also exists something like SPIRV-Cross which promises to be able to generate code from the SPIRV intermediate representation into Metal and all versions of GLSL and HLSL. I am not sure really how good it is at this point, but going forward we might start to see more high-level shader languages, that compile to SPRIV and then from there to the myriad of different shader formats different platforms expect.

If you have shaders, I believe you can use SPIRV-Cross to generate GLSL, which you can probably get to pass as OpenCL C with just a bunch of macro tweaks, or at worst some small changes to spv-cross.

Regarding reflection, here is a guide: https://github.com/KhronosGroup/SPIRV-Cross/wiki/Reflection-API-user-guide

I am working on an engine that targets Vulkan and Metal. I'm at the point now where I want to be able to dynamically update my shader at runtime to suit the type of data being sent in for drawing. I am currently using offline compilation for my GLSL (for Vulkan) and MSL (for Metal) shaders. What are your workflows for situations like this? For those using tools like SPIR-V Cross and shaderc, what has your experience been with these tools keeping up to date with the latest features in the specs?

For cross-platform support look at WebGPU and Vulkan (e.g,: [0] [1]. Essentially, you would need to write the func in WGSL or GLSL, HLSL or MSL. Each of these can be cross-compiled to SPIR-V (what Vulkan needs) with cross-compilers such as spirv-cross and naga.

Just for reference, the library I'm using (both for compiling the shaders and for reflection), is SPIRV-Cross by the Khronos Group and here you have the docs for the reflection API. I wanted to check out `glslang` but honestly this one so far has worked like a charm.

Aside from SPIRV-Reflect, if you're using SPIRV-cross to cross compile your shaders, there is also a --reflect arg you can pass which spits out reflection info in JSON format. We already need to cross compile from spirv, so it just removes a tool in the chain to depend on.

For your own engine, use the format your API uses. If you need crossplatformness, there is a new path available. Write your shaders in a language that compiles to SPIR-V (HLSL/GLSL are the most obvious languages), and then use SPIR-V Cross to compile the SPIR-V back to HLSL/GLSL for other API to consume.

I actually did that too. I tried using google's shaderc to compile my existing OpenGL 4.3 codebase to SPIRV binaries and load it from a OpenGL 4.6 context. Sadly this did not fix my issue, the Nvidia compiler crashed the same way.

Do you mean how to compile Spir-V at runtime? shaderc repo has an example https://github.com/google/shaderc/tree/main/examples/online-compile

_ _ ___| |__ __ _ __| | ___ _ __ / __| '_ \ / _` |/ _` |/ _ \ '__| \__ \ | | | (_| | (_| | __/ | |___/_| |_|\__,_|\__,_|\___|_| shader helps you with compiling your GLSL files into SPIR-V byte code. Examples: | > shader --webservice | | Use webservice to automatically compile all *.glsl files in this project. | > shader --webservice --watch | | Watch for file system changes and use webservice to compile *.glsl files. | > shader --webservice --dart | | Generates a .dart-file with a loading function instead of byte code. | > shader --webservice --put-in-assets | | Places compiled files into the Flutter assets directory. | > shader --local /path/to/shaderc | | Use local executable of glslc by pointing to a directory to look for it. Usage: -s, --webservice Use a hosted webservice to compile local *.glsl files. -l, --local Use a local executable of the glslc compiler. Specify the path to a location where shader_cli should scan for the glslc executable. Download: https://github.com/google/shaderc -c, --custom-webservice Uses a self-hosted webservice to compile *.glsl files. You can download the webservice at: https://github.com/felixblaschke/shaderc_webservice -w, --watch Watches for file system changes and automatically recompiles the *.glsl files. -p, --path Defines a directory path to scan for files to compiler. If unset, it will use current working directory. -a, --put-in-assets Places the compiled files into this project's assets directory. -d, --dart Generates Dart-file with embedded SPR-V byte code and a simple shader loading function. -h, --help Shows this help text. Updates and more information: https://pub.dev/packages/shader_cli

I am working on an engine that targets Vulkan and Metal. I'm at the point now where I want to be able to dynamically update my shader at runtime to suit the type of data being sent in for drawing. I am currently using offline compilation for my GLSL (for Vulkan) and MSL (for Metal) shaders. What are your workflows for situations like this? For those using tools like SPIR-V Cross and shaderc, what has your experience been with these tools keeping up to date with the latest features in the specs?

I can;t edit the post for some reason, you can find it in the issue I posted in the library: https://github.com/google/shaderc/issues/1235

go to https://github.com/google/shaderc/blob/main/downloads.md and download the version for linux unzip the downloaded folder, assumin you unzipped it in downloads, run the following command in the terminal sudo cp /home/{user}/Downloads/install/bin/glslc /usr/local/bin, cp command copies the target file to target location, you cant drag and drop because copying to local/bin requires special permissions :)

This was reported as bugs already, status remain undecided. ``` shaderc``` package have been flagged out of date already as the upstream has released tag 2021.3 while it's still on 2021.2 in extra repository. Is this the cause of error?

shaderc (https://github.com/google/shaderc) is one such shader compiler. It does the job well enough and lets us compile our GLSL shader code into the SPIR-V assembly that the graphics drivers need. However, it's written mostly in C++ and has a rather complicated build system. This means that people wanting to compile Veloren need to install a variety of extra things to get shaderc working with Veloren.