-
Notifications
You must be signed in to change notification settings - Fork 6
Description
As the library is getting closer to generating SPIR-V code, one question starts to draw itself : What file format(s) should we use for storing shaders as assets for the Stride engine or other engine ?
Ideally, the library can be a plug and run compiler for shaders used for Stride (primarily) but also usable for other engines or frameworks.
Considerations
Currently, Stride stores shaders as text assets. It is loaded once and goes through the process of parsing, AST building, AST modifications and translation, and finally, those shaders are compiled as binaries and cached for future reuse.
For this new shader compiler a shader file goes through different formats, many similar to those previously used:
- A text file :
*.sdslfiles can contain one or many shader classes - A parse tree generated by the Eto.Parse library and the SDSL grammar defined
- An AST built from the parse tree
- Many
Quadruplearrays representing each method in three address code for optimization purposes. - A SDSL flavored SPIR-V (that i want to call
sdspv), it's invalid SPIR-V but has enough information to be mixed together. - Compiled SPIR-V modules
Favored way of writing shaders
The most important format in the previous list is sdspv. It's a binary format that is very close to SPIR-V but has the advantage of being mixed the same way SDSL would be done on the AST level.
Given the nature of the composition system that SDSL and SDFX offers, there's a high value in writing shaders only at design time and composing them through the SDFX either at design time or at runtime.
During the asset compilation, the shader compiler should compile those shaders into sdspv binary files, known permutations will be compiled as SPIR-V modules directly.
- SPIR-V modules can then be directly consumed by Vulkan, wgpu and OpenGL 4.6, removing the need to parse and translates shaders.
sdspvshaders can be mixed at runtime and translated using naga, tint or spirv-cross.- For Windows platforms, we can ship the dxc compiler using the official nuget package
- For Android platforms using OpenGL ES, the driver will consume the GLSL translation directly
- For console platforms, a lot of the work can be done by a private company, but here are some thoughts
- The Nintendo Switch has a Vulkan driver which could potentially consume the SPIR-V generated
- The Xbox console runs with DirectX, we might have very little changes compared to Windows Desktop platforms
- The Playstation 4 and 5 uses a proprietary driver and shader language. There is not much we can do on our side to make it work on these platforms. There might be some work done by the folks at FNA or Monogame on this front.