naga support

[stefnotch]

Eventually, we might need proper support from naga to be able to handle all WGSL constructs. (The hard alternative is rolling our own parser.)

Currently, naga_oil generates headers and uses them to compile modules individually.

However, generating WGSL headers breaks down when they include a predeclared type which gets redefined.

For example, a simple header could be

// foo.wgsl
alias LightValue = f32;
fn light() -> LightValue { return 1.0f; }

Then, if we parse code like this, it leads to an issue

// main.wgsl
#import foo::{light};

// Affects the header
alias f32 = f64;

I believe that this is very hard to fix under the current model. We currently generate WGSL code for headers, and then pass the whole code to naga.

If WGSL were slightly more expressive, then this would also no longer be an issue. For example https://github.com/gpuweb/gpuweb/issues/4308 would let us fix this.

[ncthbrt]

The right way to treat this would be to also mangle the aliases surely? Wouldn't that avoid the problem?

[stefnotch]

Yes, that's what should happen in the generated output.

But, naga-oil currently fully relies on naga to do the shader parsing. As in, to parse a module, we roughly do

let mut module_string = String::new();
module_string.push_str(&composed_header); // Can depend on f32
module_string.push_str(&source); // Can alias f32. Breaks the header. :(

let module = naga::front::wgsl::parse_str(&module_string);

[ncthbrt]

I see. Yeah you're right and precisely why I want to move away from that model.