Simplify egui wgpu fragment shader, remove redundant color conversions

[PPakalns]

By default on desktop gpu devices egui_wgpu / wgpu outputs preferred target format wgpu::TextureFormat::Bgra8Unorm.

Then for rendering it renders to this texture in gamma space (srgb ?)

https://github.com/emilk/egui/blob/master/crates/egui-wgpu/src/egui.wgsl#L84C1-L91C2

@fragment
fn fs_main_gamma_framebuffer(in: VertexOutput) -> @location(0) vec4<f32> {
    // We always have an sRGB aware texture at the moment.
    let tex_linear = textureSample(r_tex_color, r_tex_sampler, in.tex_coord);
    let tex_gamma = gamma_from_linear_rgba(tex_linear);
    let out_color_gamma = in.color * tex_gamma;
    return out_color_gamma;
}

As i understand it happens like this:

• Texture is in Bgra8UnormSrgb ,
• texture view for this texture is in Bgra8UnormSrgb,
• Target texture format is in Bgra8Unorm,
• This causes in the shader automatically Srgb values to be converted to linear values.
• Then in the shader rgb value is converted back to srgb value.
• Then srgb value is outputted to Bgra8Unorm texture instead of Bgra8UnormSrgb. (Because device expects srgb value outputted to it, (intuition would tell that this expects linear rgb value))

Similar thing happens for user registered textures.
I need to provide view to srgb texture with Bgra8UnormSrgb format so that shader receives values in linear format.

It looks like it causes double conversion from srgb -> rgb -> srgb. Couldn't this be avoided by only storing textures in srgb format and using everywhere Bgra8Unorm texture view format view which doesn't cause conversion, therefore no need to convert from linear to gamma space in fragment shader.

As I understand, texture formats and their views are only for automatic color conversion in shader and doesn't represent the real target texture color format. Is this correct understanding?
At least it looks like wgpu preferred target texture is in Bgra8Unorm format but expects textures in gamma (srgb) outputted to it.

Summary:

It looks that we can simplify fragment shader:

• Remove all color conversions in: https://github.com/emilk/egui/blob/master/crates/egui-wgpu/src/egui.wgsl#L84C1-L91C2
• Reduce color conversion count from 2 to 1 in case of srgb aware target texture format: https://github.com/emilk/egui/blob/master/crates/egui-wgpu/src/egui.wgsl#L76 (We need to output linear format (rgb) color format and gpu itself does color conversion to srgb)

Possible problems

One case where this doesn't work is if someone wants to mix textures that are stored in bgr, srgb color spaces.
What are the best practices, are these color conversions in shader costly?

[PPakalns]

Good description about gpu color conversion:
https://github.com/gfx-rs/wgpu/wiki/Texture-Color-Formats-and-Srgb-conversions

[Wumpf]

arguably there needs to be 4 combination:

• fs_main_linear_framebuffer_8UnormSrgb_texture (equal to today's fs_main_linear_framebuffer_8UnormSrgb_texture)
• fs_main_linear_framebuffer_8Unorm_gamma_texture (has conversion only at return)
• fs_main_gamma_framebuffer_8UnormSrgb_texture (equal to today's fs_main_gamma_framebuffer)
• fs_main_gamma_framebuffer_8Unorm_gamma_texture (has no conversion!)

This is only that way egui can deal with incoming textures (which are at least right now to be expected to be 8UnormSrgb) in the correct way. This wouldn't give us removing any of the color conversion code but it would allow egui_wgpu to choose the path with the least conversions for textures it created itself.

Any of these conversions is fairly cheap in the grad scheme of things so I wouldn't worry about it too much. One could easily argue that all this would just unnecessarily bloat and complicate things

Btw. the reason why egui prefers non-gamma-aware framebuffers and does blending in gamma space is detailed here #2071