Precompiled Shaders

[dfrg]

I am working with @raphlinus on piet-gpu and we're considering replacing our internal HAL with wgpu-hal but we would like to retain the ability to use precompiled shaders to reduce both binary size and startup cost.

After some investigation, it seems the least invasive solution would be to add variants to ShaderInput for MSL source (or potentially a MTLLibrary instance) and DXIL and feed those through to pipeline creation in the same way that SpirV works for Vulkan today. This would require the user to assign bindings that are compatible with those generated by wgpu-hal during pipeline layout creation. For our purposes, this would be an acceptable constraint.

Alternatively, we've also considered a more sophisticated approach that would allow the user to provide a bind mapping during shader module creation. This seems to require deferring native resource binding until the whole pipeline state is known so that discrepancies between the pipeline layout and the expected binding slots for the entry point can be reconciled.

My understanding is that the project is amenable to such a change, and we're willing to do the work, but wanted to provide an opportunity for other potential users who are interested in this feature to weigh in and develop a consensus on the best path forward.

[cwfitzgerald]

We definitely would be interested in having this feature!

A couple considerations to keep in mind:

• In the mid-term future it will be possible to write custom wgpu-hal backends out-of-tree. This is particularly important for console API backends where NDAs are involved, but can also be useful for "trying weird stuff" kind of deals. This means we cannot easily just have enums of choices, as some choices may be unknown to us.
• I think we should keep the wgpu-authoritative binding model. While specifying the binding model is possible, it is a lot of information to pipe through and is inherently a very leaky abstraction, and suffers from the above problem.

As such I would propose an api that looks something like this:

// Replaces ShaderModuleDescriptorSpirv
pub struct ShaderModuleDescriptorRaw<'a> {
    pub label: Label<'a>,
    /// Raw data of whatever type the backend needs - likely Vec<u32> or a string. Maybe something fancier like a MTLLibrary wrapper.
    pub source: Box<dyn Any>, // Maybe a custom trait?
}

// Replaces create_shader_module_spirv
//
// Note the taking of the descriptor by value.
pub unsafe fn create_shader_module_raw(&self, desc: ShaderModuleDescriptorRaw) -> ShaderModule

Then inside each wgpu-hal backend we can properly document how bindings get mapped based on all possible arguments to a pipeline creation.

[Wandalen]

@cwfitzgerald, what about the web backend? Does this proposal respect webgl?
The largest obstacle for me is the unreasonably large size of the binary.

[cwfitzgerald]

@Wandalen sure - the webgl/gles backend could accept raw glsl shaders with string as it's type.

[parasyte]

See also: #1464

According to some basic stats from twiggy (a WASM size profiler), the biggest chunk of code (about 15%) in a small wgpu project is the naga parser and writer.

[caesay]

Not a graphics programmer so can't weigh in on the specifics here, I'm just someone humbly trying to use a 2D renderer that happens to require shaders. I'd like to use the DX12 backend, but support for pre-compiled DXIL feels like an absolute necessity for this.

Right now my understanding is that any shader must be compiled to DXIL at app startup using Naga + Fxc (very slow and unmaintained) or DXC (faster but still very slow, and requires me to ship proprietary DLL's with my app!!!). There absolutely must be a way to compile shaders during my own app's compile, so I embed DXIL with my app and can avoid shipping DXC... Plus the startup time with FXC/DXC is absolutely abysmal.