get proper texture format after the renderer is initialized, fix #3897

[VitalyAnkh]

Objective

There is no Srgb support on some GPU and display protocols (for example, Nvidia's GPUs with Wayland). Thus TextureFormat::bevy_default() which returns Rgba8UnormSrgb or Bgra8UnormSrgb will cause panics on such platforms. This patch will resolve this problem. Fix #3897

Solution

Make initialize_renderer expose wgpu::Adapter and use wgpu::Adapter to get proper TextureFormat.

Changelog

• Fixed #3897

[VitalyAnkh]

@superdump Thanks for your kind reply! Now I have removed the unused dbg!. The latest code now add AvailableTextureFormat resource to the World and use it for future use. I know the available TextureFormat should be computed per Surface, but it's still better than hard-coded values. And then we don't need to expose Adapter now but the code still does so now (if Bevy developers think it's useful, could I do it in another PR?). And I add a GpuImage field to UiPipeline to specify correct TextureFormat in impl<S: SpecializedRenderPipeline> SpecializedRenderPipelines<S>. The code still needs much tuning, but it could fix #3897 correctly now.

[VitalyAnkh]

Oops... It fails on x11 now. I will push more fixes.

[VitalyAnkh]

I think this PR could pass all checks now and with this, there won't be any "no available texture formats" error anymore. But the design still needs discussion. For example, should I expose Adapter in the World? And to make MeshPipe UiPipeline and SpritePipeline get the right TextureFormat, I add a GpuImage field to them, should I do this? Are there better ways to solve this problem?

[bemyak]

I've just run into the issue that this PR addresses. Any plans on getting it merged?

[VitalyAnkh]

@superdump @alice-i-cecile hi, what do you think about this PR? What should I do to get this merged?

[superdump]

I’ll give this another look over soon. I would like to have reviewed this and other things already but life is what it is. I appreciate your patience.

[bemyak]

Friendly bumping @superdump and @alice-i-cecile to review this PR :heart:

[VitalyAnkh]

@alice-i-cecile @devil-ira Hi! Following your kind reviews, I have updated this PR. All the problems you proposed should be resolved. Please let me know if there is anything that should be improved, thanks!

[VitalyAnkh]

The latest force push makes prepare_view_targets use Res<RenderTextureFormat> other than Res<AvailableTextureFormats> to get proper texture format. It doesn't touch codes that have been reviewed.

[irate-devil]

I had some trouble with refresh rates with a multi-monitor setup, so I switched to wayland and then bumped into this issue myself. I tried this PR, and while it does run, the colors aren't correct.

[VitalyAnkh]

@devil-ira This works as expected. The texture format in your image should be Bgra8Unorm other than Bgra8UnormSrgb, so it's definitely not correct. The real problem is winit (v0.26.0) on Nvidia GPU and Wayland can't get surface with Srgb colors, but this problem has been resolved in https://github.com/rust-windowing/glutin/pull/1435. After bevy migrates to the new winit the color should be correct. Bevy should work on Nvidia and Wayland with the new winit, even without this PR, but I think it's reasonable to get texture format at runtime other than pre-defined.

[VitalyAnkh]

After bevy migrates to the new winit the color should be correct. Bevy should work on Nvidia and Wayland with the new winit, even without this PR

Correction: Bevy also needs wgpu v0.14.0(https://github.com/gfx-rs/wgpu/releases/tag/v0.14.0) to have the winit Srgb issues fixed.

[bors[bot]]

Pull request successfully merged into main.

Build succeeded:

• build-and-install-on-iOS
• build-android
• build (macos-latest)
• build (ubuntu-latest)
• build-wasm
• build (windows-latest)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• ci
• markdownlint
• run-examples
• run-examples-on-wasm
• run-examples-on-windows-dx12