Reason for hard-linking Vertex and Fragment shaders?

[CAMongrel]

What is the reason for requiring both a vertex and fragment shader when using the factories to create Shaders?

In my engine I'd like to:

• Create a single VertexShader for static meshes (and only compile it once)
• Have multiple FragmentShaders for different kinds of static meshes
• Then combine the single VertexShader in the various pipelines/shader sets with whatever FragmentShader is needed for the respective mesh.

Maybe I just couldn't find the correct way, but there doesn't seem to be a workflow that allows a single shader stage to be compiled from a generic language (like GLSL) to the currently used backend (whichever that may be depending on the running platform). (Refer to the CreateFromSpirv ResourceFactory extensions)

[mellinoe]

This is done because in order to generate the appropriate Buffer/Texture/Sampler "binding slots" for some API's (HLSL, MSL), the full set of resources needs to be known ahead of time. For example, a fragment shader might use two Textures, but they can't be assigned slots 0 and 1, because the vertex shader it is linked with might use two more Textures in a lower set. Likewise, a vertex shader might use one or more Buffers, but its linked fragment shader might use Buffers in a lower slot, which pushes the vertex shader's slots forward.

For your scenario, I'd recommend manually compiling to SPIR-V for your source shaders and caching the results. This will avoid doing the GLSL->SPIR-V compilation extra times, but you will still need to perform the SPIR-V -> compilation for each unique shader set.

[CAMongrel]

Ok, thanks for your response. I'll try that. Thanks for your great work, by the way. I realize that getting all these different kinds of APIs under a single roof isn't trivial. Closing this issue now.