Standardize #include #1
Comments
|
Yep, it'd be great to converge on syntax extensions for wgsl. Some starter comments in response to your questions:
|
Very good question. I think not, since C style
Ah, that's good to know. So file paths have a reasonably decent argument against them. One non-obvious detail when using modules is where does a language server look?
I haven't even thought about #export s yet. Does a minimum viable prototype need them, or should we focus on imports with everything being public first? And for
It's not a strict requirement, but it'd be very helpful to have a recommended mangling strategy. Ideally one that is
One place where the name mangling could leak into user code is when creating a shader. When one creates a render pipeline, one needs to specify |
There's arguments for paths as well. Relative paths to files make sense on the web. And relative paths make sense to me for 'inside my wgsl package' references. But forcing references to other packages to be magic paths seems awkward. e.g. importing from
I'll have to look more closely.. I see
Good question. A first step might be to just have an array of globs where the the wgsl files are to be found, like https://www.typescriptlang.org/tsconfig/#include. For web projects, give that field a name and stick in package.json and expect that the language server would find it there.
Hah, and I hadn't thought about not having them :-). Seems like basic functionality would work with everything exported by default.. Of course, most languages have a way to distinguish public vs private parts of the interface. I imagine we'd want that too eventually. The wgsl-linker also has an experimental feature where you can pass arguments from imports to exports, so you can do things like I didn't see an approach to generics glancing through naga_oil. Is there something? If not, something similar to import/export parameters might prove useful there too.
It's a bit odd to put extensions in comments for sure. The charm is that some tools e.g. wgsl code formatters can remain blissfully extension unaware. And it is constraining to try and maintain wgsl compatibility. Whether maintaining wgsl compatibility is preferable on balance is unclear.
To avoid this particular issue, wgsl-linker doesn't mangle the names in the main module. (Generally, it tries not to mangle names unless necessary, to ease debugging.) Is that sufficient to dodge the need for standard mangling rules? I bet there are some other reasons you are thinking about mangling standards, though.. |
Relative paths definitely make sense. There's even an open request for bevy/naga_oil to include a relative import syntax, like
On that note, feel free to join the Bevy Discord server
That'd be a reasonable future proposal. One interesting part there is that WGSL is planning on getting some features that take care of a few #define use-cases. For example, generics and function overloading gpuweb/gpuweb#876 . There's also constant evaluation built-in into the language.
Sounds reasonable, that's what almost everyone seems to expect. A config file that says "look here" and can optionally also say "look at the package.json/cargo.toml", depending on which ecosystem a tool is built for. (For example, it currently wouldn't make sense for https://github.com/ScanMountGoat/wgsl_to_wgpu to support npm. But it would absolutely make sense for it to support the cargo package manager.)
True. And re-exporting a module would also be useful.
I'm not entirely sure. naga_oil has #defines, and the ability to override functions. I think those might not cover the same use-cases though.
I suppose this would need some testing to figure out what exactly we want. If most shaders that come with imports also make use of a preprocessor, then there wouldn't be much of a reason to maintain wgsl compatibility.
Most mangling approaches are pure functions. For example C++ mangling takes a name, and mostly just slaps the full (and unique) path of the module in front of it. This saves one the trouble of keeping a global HashMap of all the used names. Of course with that approach, in a worst case scenario, almost everything needs to be mangled. // bar.wgsl
#export
fn rand() -> u32 {
return 4; // very random, I know
}// foo.wgsl
#import rand from bar.wgsl
fn extra_rand() -> u32 {
return rand() + rand() - rand()
}// main.wgsl
#import extra_rand from foo.wgsl
fn bar_rand() {
return 3;
}
fn main() {
let rand = extra_rand();
}Then to put everything into one module, we have to mangle the names.
Although, I suppose this wouldn't be much of an issue. If the mangling scheme for the entry point is simple enough, then it shouldn't be too bad to ask the user to write Another reason why I'm proposing this is because wgsl_to_wgpu asked for a way to easily un-mangle a name. I believe it wants to look at the generated source code, and generate sensible Rust equivalents. And the generated Rust equivalents should be namespaced, hence the "unmangling" request. Finally, I thought this was interesting: |
Would you be interested in helping with standardizing the #include syntax? (separate from the official WGSL specification)
After all, it'd be amazing if a number of tools could interoperate flawlessly! How neat would it be to be able to use wgsl-linker at runtime in a browser, while getting syntax checking from vscode-wgsl
To that goal, I think we'd best start by checking out the status quo, figuring out the concrete goals, and going from there.
e.g.
Q: Why is a simple text-inserting version of
#includenot satisfactory?A: One could import a function with the same name. One also runs into problems when a file is included multiple times. Therefore we need a syntax-aware importing mechanism
Q: Which path syntax would make sense for an importing mechanism?
A: ...?
Q: How does one unambiguously parse includes? And deals with cases such as "a #include inside a comment shouldn't be parsed"
Q: Name mangling?
and so on.
My personal concrete goals would really be
I've also started a discussion at
bevyengine/naga_oil#83
The text was updated successfully, but these errors were encountered: