wgsl optmizations?

[Mark Sibly]

Hi,

Does the WGSL compiler (tint?) do much in the way of optimization?

I did a quick test to see if a simple function call was being inlined and it appears not - according to the output of the dump_shader logging and my *very* limited understanding of SPIRV anyway.

The code I tested was...

fn evaluateFragment() -> vec4f {
return vec4f(1.0, 0.0, 0.0, 1.0);
}

@fragment fn fragmentMain() -> @location(0) vec4f {
return evaluateFragment();
}

...vs a fragmentMain() that directly returned the same vec4f.  The more complex version appears to involve an extra function call in the SPIRV disassembly, where-as I was kind of expecting/hoping it to be inlined. Perhaps this stuff is optimized further down the pipeline somewhere?

If not, it'd be nice to know what we can do to help the compiler out, eg: should we be inlining stuff by hand in cases like the above?

Bye!

Mark

[Corentin Wallez]

Hey Mark,

At the moment Tint (Dawn's WGSL compiler) is currently built as a compiler that translates from WGSL to its output shading languages. There are a lot of code transforms applied to the input WGSL to make the translation correct, but there are no optimizations done at this time. In general a lot of optimizations are better to be deferred to the underlying driver's compiler and Tint would in the future only do "safe optimizations" like dead-code elimination, bounds checking eliminations, constant propagation etc. Inlining is not in this category because depending on the hardware, it may be better to not inline the function call, to reduce the size of the code, or it could be better to do it to reduce register usage. All of these tradeoffs are much better understood by the driver which knows exactly which hardware it targets. GPU hardware can vary wildly so it is better to defer to the driver in such cases.

Hope this helps,

Corentin

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/275241d1-892b-4c68-92e0-ab2d20a1b352n%40googlegroups.com.

[Mark Sibly]

Hi Corentin,

 

Ok, so just because the output of tint doesn't show any optimizations, there *may* still be optimizations being performed by the underlying driver? Is there any way to tell?

Basically, I'm trying to split my monolithic shader into 'fragments', so you have a material fragment, a lighting fragment, a render fragment etc. This does result in more function calls and more dead code though, so my hope was that tint (or something...) would optimize these out so I could go a bit nuts with them, esp. the dead code. This should be made easier by the fact the shader is still really monolithic as the fragments are really just text pasted together at runtime, so the compiler can still see the whole source code at once...

Bye,

Mark

[Corentin Wallez]

On Mon, Apr 17, 2023 at 10:53 PM Mark Sibly <mark...@gmail.com> wrote:

Hi Corentin,

 

Ok, so just because the output of tint doesn't show any optimizations, there *may* still be optimizations being performed by the underlying driver? Is there any way to tell?

There *will* be optimizations done by the underlying driver, and lots of them. There isn't a portable way to tell asides from benchmarking. Each vendor has proprietary tools that sometimes let you see the underlying GPU assembly but that's it. Shader Playground has some of these tools included so it could help gain an understanding of what the underlying drivers do.

 

Basically, I'm trying to split my monolithic shader into 'fragments', so you have a material fragment, a lighting fragment, a render fragment etc. This does result in more function calls and more dead code though, so my hope was that tint (or something...) would optimize these out so I could go a bit nuts with them, esp. the dead code. This should be made easier by the fact the shader is still really monolithic as the fragments are really just text pasted together at runtime, so the compiler can still see the whole source code at once...

That's likely to get well optimized, especially with dead code elimination and inlining in a bunch of cases. 

Bye,

Mark