Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Merged by Bors] - get proper texture format after the renderer is initialized, fix #3897 #5413

Closed

Conversation

VitalyAnkh
Copy link
Contributor

@VitalyAnkh VitalyAnkh commented Jul 21, 2022

Objective

There is no Srgb support on some GPU and display protocols with winit (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 first_available_texture_format, use the first_available_texture_format by default.

Changelog

@VitalyAnkh VitalyAnkh changed the title get proper texture format after the renderer is initialized, fix #3897 [draft] get proper texture format after the renderer is initialized, fix #3897 Jul 21, 2022
@VitalyAnkh VitalyAnkh marked this pull request as draft July 21, 2022 08:19
Copy link
Contributor

@superdump superdump left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to think about the consequences of adding and exposing the Adapter.

This is a good change that needs to happen.

I think further than this, probably bevy_default should be removed and replaced when the tonemapping PR lands. @cart

crates/bevy_render/src/lib.rs Outdated Show resolved Hide resolved
crates/bevy_render/src/view/window.rs Outdated Show resolved Hide resolved
@VitalyAnkh VitalyAnkh force-pushed the fix_texture_format_error branch 2 times, most recently from b9a7032 to 06166d3 Compare July 21, 2022 14:17
@VitalyAnkh
Copy link
Contributor Author

@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
Copy link
Contributor Author

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

@alice-i-cecile alice-i-cecile added C-Bug An unexpected or incorrect behavior A-Rendering Drawing game state to the screen labels Jul 21, 2022
@VitalyAnkh VitalyAnkh changed the title [draft] get proper texture format after the renderer is initialized, fix #3897 get proper texture format after the renderer is initialized, fix #3897 Jul 22, 2022
@VitalyAnkh
Copy link
Contributor Author

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?

@VitalyAnkh VitalyAnkh marked this pull request as ready for review July 22, 2022 11:58
@VitalyAnkh VitalyAnkh force-pushed the fix_texture_format_error branch 3 times, most recently from d0709dc to 728e885 Compare July 29, 2022 08:09
@bemyak
Copy link

bemyak commented Sep 5, 2022

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

@VitalyAnkh
Copy link
Contributor Author

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

@@ -79,10 +87,57 @@ impl FromWorld for SpritePipeline {
],
label: Some("sprite_material_layout"),
});
let dummy_white_gpu_image = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code duplication of this section strikes me as a bit suspicious. Is there a good way to refactor this to avoid needing to remember to add this to each pipeline?

Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First round of feedback left :) This is definitely a real issue, and the fix makes sense.

I'm not familiar enough with the details of the rendering machinery here to suggest exactly how you might fix that code duplication issue, but the current strategy makes me suspect that any custom implementations will run into the same problem.

@superdump
Copy link
Contributor

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.

@VitalyAnkh
Copy link
Contributor Author

@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 VitalyAnkh requested review from alice-i-cecile and irate-devil and removed request for superdump and alice-i-cecile September 30, 2022 06:29
@alice-i-cecile alice-i-cecile added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Sep 30, 2022
There is no Srgb support on some GPU and display protocols with `winit` (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 bevyengine#3897

## Solution

Make `initialize_renderer` expose `wgpu::Adapter` and `first_available_texture_format`, use the `first_available_texture_format` by default.

## Changelog

* Fixed bevyengine#3897
@VitalyAnkh
Copy link
Contributor Author

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
Copy link
Contributor

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.
poroporo

@alice-i-cecile alice-i-cecile removed the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Oct 7, 2022
@VitalyAnkh
Copy link
Contributor Author

VitalyAnkh commented Oct 7, 2022

@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 rust-windowing/glutin#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.

@alice-i-cecile alice-i-cecile added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Oct 7, 2022
@alice-i-cecile alice-i-cecile added this to the Bevy 0.9 milestone Oct 7, 2022
VitalyAnkh added a commit to VitalyAnkh/bevy that referenced this pull request Oct 7, 2022
@VitalyAnkh
Copy link
Contributor Author

VitalyAnkh commented Oct 7, 2022

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.

Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a complete fix, but a necessary one.

bors r+

bors bot pushed a commit that referenced this pull request Oct 10, 2022
#5413)

# Objective
There is no Srgb support on some GPU and display protocols with `winit` (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 `first_available_texture_format`, use the `first_available_texture_format` by default.

## Changelog

* Fixed #3897.
@bors bors bot changed the title get proper texture format after the renderer is initialized, fix #3897 [Merged by Bors] - get proper texture format after the renderer is initialized, fix #3897 Oct 10, 2022
@bors bors bot closed this Oct 10, 2022
james7132 pushed a commit to james7132/bevy that referenced this pull request Oct 19, 2022
…engine#3897 (bevyengine#5413)

# Objective
There is no Srgb support on some GPU and display protocols with `winit` (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 bevyengine#3897.

## Solution

Make `initialize_renderer` expose `wgpu::Adapter` and `first_available_texture_format`, use the `first_available_texture_format` by default.

## Changelog

* Fixed bevyengine#3897.
james7132 pushed a commit to james7132/bevy that referenced this pull request Oct 28, 2022
…engine#3897 (bevyengine#5413)

# Objective
There is no Srgb support on some GPU and display protocols with `winit` (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 bevyengine#3897.

## Solution

Make `initialize_renderer` expose `wgpu::Adapter` and `first_available_texture_format`, use the `first_available_texture_format` by default.

## Changelog

* Fixed bevyengine#3897.
Pietrek14 pushed a commit to Pietrek14/bevy that referenced this pull request Dec 17, 2022
…engine#3897 (bevyengine#5413)

# Objective
There is no Srgb support on some GPU and display protocols with `winit` (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 bevyengine#3897.

## Solution

Make `initialize_renderer` expose `wgpu::Adapter` and `first_available_texture_format`, use the `first_available_texture_format` by default.

## Changelog

* Fixed bevyengine#3897.
ItsDoot pushed a commit to ItsDoot/bevy that referenced this pull request Feb 1, 2023
…engine#3897 (bevyengine#5413)

# Objective
There is no Srgb support on some GPU and display protocols with `winit` (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 bevyengine#3897.

## Solution

Make `initialize_renderer` expose `wgpu::Adapter` and `first_available_texture_format`, use the `first_available_texture_format` by default.

## Changelog

* Fixed bevyengine#3897.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Bug An unexpected or incorrect behavior S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

OS-independent texture format setting in swapchain
5 participants