Standard shaders are binary blobs

[timoore]

VSG's standard shaders, for pbr, phong, and flat lighting, are created at runtime by functions that read a binary .vsgb file that is embedded in C++ source and thence in libvsg. The binaries include all the common variants of the shaders, as detailed by @robertosfield in https://groups.google.com/g/vsg-users/c/VEENdu2gdbc . Unfortunately, the source code for the shaders lives in the vsgExamples tree, and the .cpp files that contain the binary data need to be built with a working version of vsg! There is no automatic rule for this, and I don't think the official list of variants exists in any file.

Thus, it's hard to make changes to the standard shaders and test them with much confidence. The only way to make a pull request to change a shader is to do a PR against vsgExamples, after which the maintainer has to regenerate the files in VulkanSceneGraph.

I see two approaches to fix this. I've done a bit of research into both and am willing to do the work to fix the situation, but I'd like some discussion first. The shader source code and the official list of variants would live in the VulkanSceneGraph repo in both approaches, and the .cpp files with the hex data would be generated during the build.

The first approach uses only the Vulkan SDK shader compiler and CMake to create the .cpp files. CMake can generate C++ files with hex data. Some amount of CMake code would have to be written to generate all the shader variants and assemble them into the library. The binary data would not be .vsgb, but .spv.

The second approach is to build a mini-VSG that doesn't include the built-in shaders, and then use that at build time to create the C++ source files. I've experimented with this and did create such a thing. It wasn't very mini, but it was feasible. This miniVSG would need to be generated with the host compiler in a cross-compile / embedded setup. That adds time and complexity to the build and the source files. I don't think the requirement to have host compilers is onerous.

The first approach is simpler, doesn't require a bootstrap phase, and allows much faster turn-around time for testing changes to VSG and the shaders. ON the other hand, as VSG's shader system evolves, it may become quite hard to generate the shader binaries using only CMake scripting.

Thoughts?

[robertosfield]

The built-in shaders aren't just compiled in .spv, they are full blown vsg::ShaderSet that include all the introspection capabilities required for mapping the uniforms, arrays, supported defines and all the pre-compiled SPIR-V variants.

This means it has to be a VSG specific solution that is able to compile all the required variants and all the extra settings of required to create a ShaderSet. The easiest way to create this right now is to use the VSG's serialization support for writing to .cpp and then use this at runtime to read it back into a vsg::ShaderSet when required.

Presently I use the following simple shell script to rebuild the built-in shaders, with vsgshaderset example in vsgExamples providing the required setup of ShaderSet that will be serialized to .cpp.

cd ${VSG_DIR}
find ~/Data/glTF-Sample-Models/2.0 -name "*.glb" -o -name "*.gltf" | xargs vsgshaderset --pbr -o src/vsg/utils/shaders/pbr_ShaderSet.cpp --binary
vsgshaderset --phong -v "" -v "VSG_BILLBOARD" -v "VSG_DIFFUSE_MAP" -v "VSG_BILLBOARD VSG_DIFFUSE_MAP" -o src/vsg/utils/shaders/phong_ShaderSet.cpp --binary
vsgshaderset --flat -v "" -v "VSG_BILLBOARD" -v "VSG_DIFFUSE_MAP" -v "VSG_BILLBOARD VSG_DIFFUSE_MAP" -o src/vsg/utils/shaders/flat_ShaderSet.cpp --binary
vsgshaderset --text -v "CPU_LAYOUT" -v "CPU_LAYOUT BILLBOARD" -v "GPU_LAYOUT" -v "GPU_LAYOUT BILLBOARD" -o src/vsg/text/shaders/text_ShaderSet.cpp  --binary

I consider this area a work-in-progress, experience with using ShaderSet's in real-world applications & feedback from the community will inform how ShaderSet and associated classes evolve as well as the tool-chains that we could build around it.

Potentially one could put the GLSL shaders into the core VSG and vsgshaderset and the cpp writer, or move them into vsgXchange. For now I prefer to keep the VSG itself just the library, but I'm 100% committed to one approach or another, it's just a case of figuring out what works best for breadth of VSG developers and users.

As ShaderSet are so integral to making use of shaders flexible and extensible and they are VSG/C++ specific feature we will need any tool-chain to utilize prebuilt VSG and libraries/applications rather than off the shelf applications in 3rd party SDK's like the VulkanSDK. At best we can invoke VSG applications from CMake to do the work, but we won't be able to CMake to do the actual .cpp generation.

[timoore]

The built-in shaders aren't just compiled in .spv, they are full blown vsg::ShaderSet that include all the introspection capabilities required for mapping the uniforms, arrays, supported defines and all the pre-compiled SPIR-V variants.

Yes. I was thinking of a change to ShaderSet that would allow it to read SPIRV from memory for a specific variation, instead of invoking the compiler. The shader set .cpp files would live in the VSG tree in both my schemes.

This means it has to be a VSG specific solution that is able to compile all the required variants and all the extra settings of required to create a ShaderSet. The easiest way to create this right now is to use the VSG's serialization support for writing to .cpp and then use this at runtime to read it back into a vsg::ShaderSet when required.

So if a solution were to appear, it seems that you have a strong preference for generating the files using VSG and not scripts.

[robertosfield]

On Wed, 8 Feb 2023 at 10:35, Tim Moore ***@***.***> wrote: The built-in shaders aren't just compiled in .spv, they are full blown vsg::ShaderSet that include all the introspection capabilities required for mapping the uniforms, arrays, supported defines and all the pre-compiled SPIR-V variants. Yes. I was thinking of a change to ShaderSet that would allow it to read SPIRV from memory for a specific variation, instead of invoking the compiler. The shader set .cpp files would live in the VSG tree in both my schemes.

It should already be possible to assign load .spv code and assign it to a vsg::ShaderModule, then batch it with the other .spv/ShaderModule to create the complete ShaderStages that is associated with a ShaderSet variant. The .spv file itself doesn't know anything about the ShaderCompileSettings for the variant used to compile it so you'd need to provide these separately. However, it would just be simpler to compile the variants for the ShaderSet and load these as a complete shader set and load these from disk. The .spv is very information poor compared to a full ShaderSet.

This means it has to be a VSG specific solution that is able to compile all the required variants and all the extra settings of required to create a ShaderSet. The easiest way to create this right now is to use the VSG's serialization support for writing to .cpp and then use this at runtime to read it back into a vsg::ShaderSet when required. So if a solution were to appear, it seems that you have a strong preference for generating the files using VSG and not scripts.

It's not a strong preference, scripts simply won't work for generating something as complete as a ShaderSet. One could potentially create a high material description file that is parsed by a VSG based program to glue together all the shaders into a working ShaderSet, but essentially this would be equivalent to a ShaderSet serialized to .vsgt ascii file. I think it's worth remembering that we can already override the ShaderSet's that vsg::Text. vsg::Builder, vsg::TileDatabase and vsgXchange::assimp use, so if users want to use their own, or prebuilt variants into a ShaderSet then can then load this ShaderSet from disk and use it instead of the built-in ones. This ability to override the built-in is one of the key reasons why I wrote ShaderSet - trying to help decouple application/library code from the specific shaders as much as possible and provide the rules as to what those shaders will need to be compatible. The built-ins are really just a starting place.

…

Message ID: ***@***.***>