Open giantpand2000 opened 8 months ago
Currently yes, however I'm happy to take suggestions if you have other things you'd like the macro to provide - ideally one day I'd like to pass through information about features supported by the device, however this would move some of the preprocessor to runtime so it'd be a big undertaking.
My personal suggestion is to initially accept a series of predefined literal constant values and shader aliases during macro definition. These can be completed at compile time. And if necessary, they can be freely combined with cfg feature. These imports and defines can solve all the problems of static wgsl shaders.
Secondly, provide a function that accepts a set of defined values and returns a shader module. This requires the introduction of naga_oil at runtime, which can be enabled or disabled as a crate feature. However, I think those who want runtime shader generation will find their own solution with naga_oil.
ChatGPT gives me something like this:
#[shader_config(
path = "path/to/shader.wgsl",
aliases = {
"alias1": {"DEFINE1": true, "DEFINE2": false},
"alias2": {"DEFINE1": true, "DEFINE2": true}
}
)]
Maybe aliases' names and definitions' names should be ident
s.
and definitions' values are only in three kind of literals:
pub enum ShaderDefValue {
Bool(bool),
Int(i32),
UInt(u32),
}
+1, was also looking for something like this so that I can use this crate for all static shader use.
It seems that only one define
__DEBUG
and its value added to the shader preprocessor.