Shader Compilation Workflow

[OskarGroth]

I'm trying to add a custom Material in a project that uses Satin, but it seems that the Shader/Material workflow pipeline is currently set up to only handle shader source files directly, leaving compilation stage to runtime. This works well for live-coding, but it adds extra overhead in terms of runtime performance. Additionally, when releasing an app to the public you'd probably want to compile your shader library and not leave the source code exposed in the bundle.

Is there currently no way to use compiled shader libraries, and if not, what do you think about supporting it?

[rezaali]

Thanks for bringing this up. This definitely is something I have been thinking about and experimented with. I've tried a couple different approaches and nothing feels right. As a temporary workaround I recommend putting shaders in the assets.xcassets and accessing them that way. I know this is a hack... I'll be thinking about a better solution

[rezaali]

@OskarGroth I refactored the Shader class to work for this use case. Check out the shipping example to see how it works. I'm thinking about writing a small command line tool / script that can help compile shaders into the format xcode wants so it can build a metallib. My ideal workflow would be live coding shaders in debug mode. Then when building for release there is an xcode run script that calls a satin command line tool to compile the satin shader and then include that in the xcode project so xcode can make a metallib and remove the shader files so your shader library isn't exposed.

[rezaali]

I finally got around to testing out a pre-build script to have Xcode compile a satin shader into a complete shader so xcode can build a metallib (for better runtime performance)... I ran into an issue that has prevented me from shipping this script or developing it further. When shaders are built dynamically the material that the shader belongs to sets the shader's vertex descriptor, this is used to generate the vertex (in) struct... I'm going to be working on a new shading system (pbr) and I'll be building a proper shader builder then, and I'll keep your workflow in mind.

[OskarGroth]

Just getting back to this after a break. Thanks for resolving this! I tried it out and it seems to be working with my workflow now.

Regarding a separate shader compilation tool, I personally think that it is quite nice to have Xcode build the shaders itself. There is helpful debugging information that is lost when the shaders are just text files, and compiling them is separate build step. I much prefer the guidance of the instant in-editor warnings and errors over finding out problems at build time (and looking them up manually in what I'd expect would be a text log file).

Now that Metal has features like Dynamic Libraries, Function Pointers and Function Stitching, do you see any way that Satin's shader workflow could work more natively with Xcode's shader workflow, while at the same time preserving live-coding capabilities?

[wtholliday]

Hi @OskarGroth , @rezaali and I discussed this a bit and it seems like the new Metal Dynamic Libraries will do exactly what we need. Apple's demo even shows live-coding a shader: https://developer.apple.com/documentation/metal/shader_libraries/creating_a_metal_dynamic_library