Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storing shaders as assets #2

Open
ykafia opened this issue Jan 8, 2024 · 0 comments
Open

Storing shaders as assets #2

ykafia opened this issue Jan 8, 2024 · 0 comments
Labels
rfc Request for comment

Comments

@ykafia
Copy link
Collaborator

ykafia commented Jan 8, 2024

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 : *.sdsl files 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 Quadruple arrays 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.
  • sdspv shaders 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.
@ykafia ykafia added the rfc Request for comment label Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rfc Request for comment
Projects
None yet
Development

No branches or pull requests

1 participant