MSAA causing render artefacts in Sprites

[NiklasEi]

Bevy version

0.12

Operating system & version

Ubuntu 18.04

What you did

Run the bevy sprite example

What you expected to happen

See a nice Bevy icon.

What actually happened

Additional information

I tracked this change down to c2da780 (this commit added MSAA to sprites). Turning off MSAA with app.insert_resource(Msaa { samples: 1 }) resolves the issue.

Part of vulkaninfo output:

GPU0:
VkPhysicalDeviceProperties:
---------------------------
	apiVersion     = 4202691 (1.2.195)
	driverVersion  = 88092674 (0x5403002)
	vendorID       = 0x8086
	deviceID       = 0x3e9b
	deviceType     = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
	deviceName     = Intel(R) UHD Graphics 630 (CFL GT2)

[Davier]

The png is 768x99 pixels, loading the atlas with these parameters works as expected:
#[asset(texture_atlas(tile_size_x = 96., tile_size_y = 96., columns = 8, rows = 1))].
I suspect that before c2da780 the sprites were rescaled to 100*96.

[NiklasEi]

Yeah, I just found that bug too and fixed it. That doesn't fix the render artefacts though.

[Davier]

Yeah, I just found that bug too and fixed it. That doesn't fix the render artefacts though.

That's strange, this commit did fix it for me.

[Davier]

Actually, I don't have any artefacts on the previous commit (v0.8.0) either, it only had the size issue. I can't reproduce. Could you detail your OS and GPU?

[NiklasEi]

I can also reproduce the artefacts with the sprite example

on 32f7997

on c2da780

[NiklasEi]

Actually, I don't have any artefacts on the previous commit (v0.8.0) either, it only had the size issue. I can't reproduce. Could you detail your OS and GPU?

I added some vulkaninfo output to the PR description.

[rparrett]

Is this related to #3423?

Not seeing this on windows/nvidia or mac/m1

[Davier]

I think the only rendering change for sprites in this commit is enabling MSAA. Could you try to disable it?

app.insert_resource(Msaa { samples: 1 })

[NiklasEi]

I think the only rendering change for sprites in this commit is enabling MSAA. Could you try to disable it?

app.insert_resource(Msaa { samples: 1 })

That fixes it for me

[lemunozm]

Hi! Same issue here.

• Ubuntu 20.04.02.
• Adapter: Intel(R) UHD Graphics 620 (WHL GT2).

But I also notice that the background darkens with msaa enabled.

msaa 1:

msaa 4:

msaa 2 and 8 values make the application crash at starting

[johanhelsing]

I'm seeing the same thing on both wayland and x11, but not wasm (also linux, same machine) and not on windows.

Areas of the screen where there is no blending going on are too dark. Looks right when I set MSAA to 1.

I'm also on Intel UHD.

Let me know if there is anything I can add/do to help.

[tim-blackbird]

The darkened colors suggest this issue may have been caused by Bevy picking an incorrect surface format, which should be fixed on main.
If anyone affected could test it again, that would be great.

[NiklasEi]

I can still reproduce this on fdec72b

[JamesGallagherPoole]

This is happening for me too. I am getting darkened colours and artefacts before and after updating to 0.11.

I'm on a linux laptop with Intel UHD. Setting Msaa to off fixes the problem.

Example of with Msaa:

Example of without Msaa:

[billymosis]

same here. I'm on older hardware
before disabled:

fn main() {
    App::new()
        .insert_resource(Msaa::Off)
}

after:

spec:

[mockersf]

is the background color change also just from the msaa change?

[JamesGallagherPoole]

It is for me anyway!

[billymosis]

is the background color change also just from the msaa change?

Yes

[mockersf]

Seems everyone affected is on Linux with an Intel integrated GPU

It looks like gfx-rs/wgpu#725 came back... @cwfitzgerald are you aware if that's the case?

[NiklasEi]

I can no longer reproduce this, but my hardware has changed. Can someone with hardware that had the issue in previous versions check 0.12 please?

[JamesGallagherPoole]

Confirmed still happening for me on 0.12 with the same Intel Integrated GPU, Pop OS laptop

[fatho]

Same here. Left is using Msaa::Off, right is Msaa::Sample2, both with Color::GRAY (i.e. Color::rgb(0.5, 0.5, 0.5)) as the clear color.

It seems as though with MSAA, sRGB transformation is applied twice. When I use Color::rgb_linear(0.5, 0.5, 0.5) then I get the same color with MSAA as I get with Color::rgb(0.5, 0.5, 0.5) without MSAA.

Adapter as reported by Bevy:

AdapterInfo { name: "Intel(R) UHD Graphics (CML GT2)", vendor: 32902, device: 39745, device_type: IntegratedGpu, driver: "Intel open-source Mesa driver", driver_info: "Mesa 23.0.3", backend: Vulkan }

Minimal reproducer I used

use bevy::prelude::*;

fn main() {
    App::new()
        .insert_resource(ClearColor(Color::GRAY))
        .insert_resource(Msaa::Sample2) // Or Msaa::Off respectively
        .add_plugins(DefaultPlugins.set(WindowPlugin {
            primary_window: Some(Window {
                title: "Msaa::Sample2".to_string(),
                present_mode: bevy::window::PresentMode::AutoVsync,
                resizable: true,
                ..Default::default()
            }),
            ..Default::default()
        }))
        .add_systems(Startup, startup)
        .run();
}

fn startup(mut commands: Commands) {
    commands.spawn(Camera2dBundle::default());
}

[cwfitzgerald]

For those who are experiencing this on vulkan, can you make sure your graphics drivers are up to date? We use this ppa https://github.com/gfx-rs/wgpu/blob/trunk/.github/workflows/ci.yml#L402 to get the latest stable release of Mesa.

If this is still a problem on an updated Mesa, this is a bug to file against Mesa itself.

[fatho]

@cwfitzgerald The issue indeed persists with the latest Mesa (23.1.9 at the time of writing).

I am not sure it is a problem with the driver, however. To have something to compare against, I adapted vulkano's triangle example to use multisampling (https://gist.github.com/fatho/e7e7297ee510980bdb550928e64882aa#file-triangle-rs-L365, based on the latest master commit at the time of writing, https://github.com/vulkano-rs/vulkano/blob/795f02217a569254e53a3970d72ec52cdff39bcb/examples/triangle/main.rs).

As the clear value, I used the same 0.5 gray that I used in my bevy reproducer:

                            clear_values: vec![Some([0.5, 0.5, 0.5, 1.0].into()), None],

And it indeed aligns with the color in the Bevy reproducer without MSAA, but when MSAA is turned on in Bevy, you can see the discrepancy (left is bevy with MSAA, right is Vulkano with MSAA, both with 4 samples):

I wouldn't call myself a Vulkan expert though, and this was just a quick attempt to reproduce the issue, so I wouldn't rule out any mistakes in my adaption of that triangle example either.