search

gfx-rs / wgpu

A cross-platform, safe, pure-Rust graphics API.
https://wgpu.rs
Apache License 2.0
11.48k stars 854 forks source link

MSAA resolving produce wrong result on metal #2241

Open mikialex opened 2 years ago

mikialex commented 2 years ago

Description

Firstly, thanks for building an awesome library!

MSAA resolve result is wrong when resolve target texture is reused. For example, a texture is used as a common render target attachement last frame but used as msaa resolve target in current frame.

Repro steps

I'm prototyping a simple renderer in https://github.com/mikialex/rendiation/tree/msaa-bug, this branch can reproduce this issue(cd viewer, cargo run). The tracing file is linked below. If it is hard to debug maybe I could create another minimal example for this later.

Expected vs observed behavior

The axis helper is drawed on msaa target and resolved and copied to final target. When you click the object in window, the object's outline will be highlight, which is impl by draw highlighted object's mask, and find the edge and compose to final target. The texture reuse occurred between the hightlight mask target and msaa resolve target.

expected:

good

observed:

bad

I believe this is related to texture reuse beacuse if I disable the reuse for msaa resolving everything is fine.

Extra materials

trace.zip

Platform

The issue is reproduceable on macos 10.15.7 but not windows using wgpu 0.11.0.

I did use Xcode metal frame capture, but once I capture, the issue disappeared. No metal validation errors reported.

kvark commented 2 years ago

That's a lovely detailed issue. Thank you for taking time to gather all this info, and sorry about the issue you are seeing! I'll try to look at it today.

kvark commented 2 years ago

Note that on latest wgpu-0.11 your code triggers a validation error:

thread 'main' panicked at 'Stage { stage: FRAGMENT, error: Filtering { texture: ResourceBinding { group: 0, binding: 2 }, sampler: ResourceBinding { group: 0, binding: 1 }, error: NonFilterable } }', /Users/dmalyshau/Code/wgpu/player/src/lib.rs:300:21 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Also, it appears to work for me on Intel Iris 550 with macOS 12.1:

Screen Shot 2021-12-02 at 12 47 33

At least replaying the capture works, I mean. Have you tried?

cd wgpu/player
cargo run --features winit -- <path_to_trace_folder>
kvark commented 2 years ago

Since we aren't using any sync barriers in Metal, and it's expected to do implicit synchronization right now, and it works on both other platforms and on my Intel MBP, I'm inclined to consider this a driver bug. Please provide info about your GPU.

mikialex commented 2 years ago

I was recorded and replayed the trace at wgpu0.11.0(wgpu-core 1.11.2), seems wgpu0.11.1(with wgpu-core 1.11.3) added another validation. I fixed it and this is the new trace if it's helpful. The validation error seems not related to this issue.

trace.zip

My macbook's GPU is Intel UHD Graphics 630 and AMD Radeon Pro 5600M.

the wgpu::PowerPreference default to low power which maybe use Intel UHD Graphics 630. I tried to switch it to the high performance mode to use 5600M and this issue magically disappeared. So this likely a driver bug.

This issue https://github.com/google/filament/issues/2602 looks same.