-
Notifications
You must be signed in to change notification settings - Fork 547
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
[RFC][ll] SPIR-V as the shader API solution #1374
Comments
As awesome as this would be I assume we will be blocked here by SPIRV-Cross as it's not production ready enough afaik (even though already quite good!). |
@msiglreith I think we reached the stage where we can start playing with SPIRV and get something working, then actually spread our wings and contribute to SPIRV-cross with fixes we need. AFAIK, that's what MoltenVK did, and SPIRV->MTL is used in production, so we have a good start. |
It would be quite neat to generate shader binaries directly from SPIR-V, in order make the loading faster on those backends. FXC seems to be fairly well researched (https://github.com/google/rspirv/issues/17), and DXIL has an open-source compiler. MTL, however, doesn't appear to be open or reverse-engineered. |
I'm in favor of the SPIR-V to DXBC/DXIL approach. It involves less steps (no need to invoke the whole HLSL front end in the middle) and is more efficient. |
I think it might be better/easier to translate glsl/msl/hlsl directly from Rust (or another high level language). SPIR-V can have multiple entry points, subpasses, push constants. I am not sure how much effort it would be to translate SPIR-V into a higher level language. But translating a high level language into a high level shader language probably is also terrible, I am not sure how good the optimizers in the drivers are. I can only shiver if I imagine to translate Rusts iterators into GLSL without any optimizations. Then there is the other approach of translating from an IR like Mir or llvm-ir etc. At least you could get offline optimizations that way but it is definitely a bit more involved. There is also https://github.com/LunarG/LunarGLASS but I am not quite sure what the point is. There is no plan for a SPIR-V backend. (But it has a SPIR-V fronted so it might be able to convert to GLSL/HLSL) I know that spirv-cross currently is a bit lacking and so is the optimizer but they probably will improve over time. I currently also work on a mir -> SPIR-V backend and if everything works out I think creating a backend for other languages should not be much work. Although I have to admit that I am progressing much slower than I anticipated. |
We kind should provide both:
|
Currently, providing platform-specific shaders is the weakest part of the abstraction. It's also error-prone and maintenance heavy. This RFC is different from #71 for being focused on low-level side.
We could have a single unified API in
Factory
to receive SPIRV binary. This would work in line with #1226, and we can use SPIRV-cross to generate the backend-specific shader binaries from it. As a follow-up, we may develop a library for generating such SPIRV from Rust sources.At the same time, the backend
Factory
structs can have special methods for constructing shader modules from platform-specific shader representation. I.e. GL backends may create shaders from GLSL files. This would allow supporting the existing applications that only care about GL.We must be careful in respecting platform specifics and patching SPIRV accordingly before passing it down the toolchain:
The text was updated successfully, but these errors were encountered: