shaders cleanup

[rukai]

Once #947 is merged then, there a bunch of work I want to do on the vulkano-shaders/vulkano-shader-derive crates, in terms of updating dependencies and cleaning things up. So figured I would list my plans here:

1. delete fn build_glsl (it was used for pre proc-macros) done
2. deprecate glsl-to-spirv (change readme + publish) done
3. upgrade to proc_macro2 done
4. use proc_macro instead of proc_macro_derive done
5. deprecate vulkano-shaders-derive (change readme + publish) done
6. change panics to errors as per the syn lazy-static example - ensure this fixes Format SPIR-V Cross-Compilation Errors #345, its currently caused by unwrapping the Result<CompilationArtifact, String>
7. Use spans properly to report where errors occur.
8. Pass file names to the input_file_name argument. Filename will be either:
   • *.glsl
   • *.rs (embedded)
9. Display shaderc-rs warnings as proc macro warnings Show warnings generated by glslang #117
10. Change vulkano_shaders! to have the glsl specified as tokens rather then a string. Some discussion at vulkano-shaders - proc macros 2.0 #1062
11. Map shaderc errors back to the glsl token spans to generate better errors.
12. Replace vulkano-shaders/src/parse.rs with rspirv stuff Replace vulkano-shaders parser with rspirv #910

6,7,9,10,11 are waiting on proc macro diagnostics to stabilize rust-lang/rust#54140

[rukai]

#945 Just came across this issue, posting it here so I can find it again.

Edit: And another relevant issue - #549

[TheEdward162]

I don't know if this is the right place to ask this, but is there a plan to support shaderc #include directive? According to the shaderc-rs docs, it's just a matter of supplying a loader function in compile_options and it would really be a big help when reusing shader code.

[mitchmindtree]

@TheEdward162 ooo that would be a nice option to have. I wonder where within the vulkano API this could be exposed. I wonder - is there any drawback to just always enabling it? I'll probably look into contributing this if it doesn't happen to be supported by the time we need it. cc @JoshuaBatty relevant to our interests :)

[rukai]

Thanks for pointing that out.
I haven't seen it before and it would be nice to have.

Basic design:

• When the shader is specified as a string in the shader! macro call we dont set the callback at all.
• When the second arg is IncludeType::Standard the callback would return Err
• When the second arg is IncludeType::Relative the callback would attempt to read a shader string using the path in the first arg, starting from the directory that the compiled shader is in.