Wrong background color with the same `ClearColor` on some machines

[benfrankel]

Bevy version

0.8.1

Relevant system information

AdapterInfo { name: "Intel(R) UHD Graphics 610 (WHL GT1)", vendor: 32902, device: 16033, device_type: IntegratedGpu, backend: Vulkan }

What you did

App::new()
    .insert_resource(ClearColor(Color::rgb(0.5, 0.5, 0.5)))
    .add_plugins(DefaultPlugins)
    .run();

What went wrong

• Expected #7f7f7f as the background color.
• Saw #373737 as the background color.

Additional information

Notably, 0x37 == 55 == (0.5.powf(2.2) * 255).round(), so this issue might have something to do with gamma conversion.

On my other machine I see the correct background color #7f7f7f. Other machine's GPU:

AdapterInfo { name: "AMD RADV POLARIS10", vendor: 4098, device: 26591, device_type: DiscreteGpu, backend: Vulkan }

EDIT: Also notable that sprite colors manifest correctly on both machines. It's just the background color that's wrong.

[superdump]

What operating system, and if Linux what display server, and what driver?

[benfrankel]

OS: Linux
Display server: X11
Driver: Intel's Vulkan mesa driver 22.1.3-1 (from here https://archlinux.org/packages/extra/x86_64/vulkan-intel/)

[tim-blackbird]

That game has a lighting system, so it's the lack of a campfire causing the issue :)
As you can see, the entire scene is dark, including the trees.

[kristianmandrup]

I see. Thought as much. Worked fine in another game I'm just playing around trying to get to grips with Bevy. Thanks.

[spiderman-idog]

Having the exact same issue here, only the background color is wrong. I'm also using Linux, using an Intel graphics card with a Mesa driver. I have a dedicated NVIDIA graphics card (I have a gaming laptop) on the same machine and it doesn't have the issue

Luckily, I've found a workaround: putting INTEL_DEBUG=nofc (taken from here, according to this, it turns off something called 'fast-clear') before the run command solves the issue for me.

This really seems to be sRGB conversion problem, converting the correct color to linear RGB (used this site to convert) gets it back to the wrong color that I was experiencing.

Seems to be related to gfx-rs/wgpu#1627, they seem to also have a couple of other similar issues.

@benfrankel could you try the workaround and say if it worked?

[rdbo]

Having the exact same issue here, only the background color is wrong. I'm also using Linux, using an Intel graphics card with a Mesa driver. I have a dedicated NVIDIA graphics card (I have a gaming laptop) on the same machine and it doesn't have the issue

Luckily, I've found a workaround: putting INTEL_DEBUG=nofc (taken from here, according to this, it turns off something called 'fast-clear') before the run command solves the issue for me.

This really seems to be sRGB conversion problem, converting the correct color to linear RGB (used this site to convert) gets it back to the wrong color that I was experiencing.

Seems to be related to gfx-rs/wgpu#1627, they seem to also have a couple of other similar issues.

@benfrankel could you try the workaround and say if it worked?

I have the same issue on my machine (also Intel iGPU with Mesa driver, running X11 on Alpine Linux, bevy v0.9.1)
The INTEL_DEBUG=nofc workaround did fix it for me.

[rdbo]

I found out that enabling the Msaa resource with samples: 1 also fixes this bug on Bevy 0.9.1:

App::new()
// ...
    .insert_resource(ClearColor(Color::rgb(0.1, 0.1, 0.1)))
    .insert_resource(Msaa { samples: 1 } )
// ...

Without MSAA and without INTEL_DEBUG=nofc (completely black background, aliased image edges):

With MSAA and without INTEL_DEBUG=nofc (background is the right color, image no longer aliased):

Without MSAA and with INTEL_DEBUG=nofc (same as with MSAA):

I'm not sure what to make off of this information, but could help going towards the right direction.

[benfrankel]

Tested on the same machine with Bevy 0.15.3, and I can no longer reproduce this issue. It seems to have been fixed! Possibly thanks to #8336, which landed in Bevy 0.14. 🎉

If someone else is able to reproduce this, feel free to re-open the issue.