bevyengine / bevy

A refreshingly simple data-driven game engine built in Rust
https://bevyengine.org
Apache License 2.0
36.71k stars 3.61k forks source link

mesh2d example panics on macOS #10849

Open ekalosak opened 1 year ago

ekalosak commented 1 year ago

Summary

cargo run --example mesh2d compiles bevy successfully but panics upon run.

Environment

Adapter

AdapterInfo { name: "Intel Iris Pro Graphics", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }

Other examples tested

bevy

wgpu

Other things tried

Panic

Here's the full console output from cargo run --example mesh2d:

    Finished dev [unoptimized + debuginfo] target(s) in 0.58s
     Running `target/debug/examples/mesh2d`
2023-12-02T21:43:50.122253Z  INFO bevy_render::renderer: AdapterInfo { name: "Intel Iris Pro Graphics", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }
2023-12-02T21:43:50.800731Z  INFO bevy_winit::system: Creating new window "App" (0v0)
2023-12-02T21:43:50.937406Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "MacOS 12.7 ", kernel: "21.6.0", cpu: "Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz", core_count: "4", memory: "16.0 GiB" }
2023-12-02T21:43:51.627927Z ERROR log: Shader translation error for stage ShaderStages(VERTEX | FRAGMENT): new_render_pipeline_state: "Compiler encountered an internal error"    
2023-12-02T21:43:51.627987Z ERROR log: Please report it to https://github.com/gfx-rs/naga    
2023-12-02T21:43:51.628043Z ERROR log: Handling wgpu errors as fatal by default    
thread 'Compute Task Pool (0)' panicked at /Users/eric/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.2/src/backend/direct.rs:3056:5:
wgpu error: Validation Error

Caused by:
    In Device::create_render_pipeline
      note: label = `transparent_mesh2d_pipeline`
    Internal error in ShaderStages(VERTEX | FRAGMENT) shader: new_render_pipeline_state: "Compiler encountered an internal error"

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_render::render_resource::pipeline_cache::PipelineCache::process_pipeline_queue_system`!
thread 'main' panicked at crates/bevy_render/src/pipelined_rendering.rs:145:45:
called `Result::unwrap()` on an `Err` value: RecvError

Notice that the ERROR log asks for a report in gfx-rs. Please let me know if this is truly a gfx-rs issue and I'll move it there. I'm posting this here because the use of direct.rs leads me to believe that Bevy tried to load DirectX support rather than, what I assume is more appropriate for my macOS workstation, the Metal graphics lib. However, notice that the AdapterInfo indicates Bevy is targeting Metal.

So, with that working theory, I'm posting here. Please let me know if I can provide other diagnostic info. The full traceback is backtrace.log.

Related issues

superdump commented 1 year ago

@cwfitzgerald this one sounds fun?

ekalosak commented 1 year ago

Workaround

Woot. Using 0.11.3 makes the mesh2d, orthographic, etc. examples work.

Note

I wonder if my antique workstation being stuck at 12.7 might be part of the issue. Apple's docs show macOS >= 10.11 and the Metal Performance Shaders are macOS >= 10.13, but - maybe?

See also

jdm commented 11 months ago

I'm also using macOS 12.7.1 and can reproduce this problem on bevy 0.12.1.

jdm commented 11 months ago

Related upstream reports:

mockersf commented 11 months ago

it seems it only crashes on macOS with intel graphics

ekalosak commented 7 months ago

Still open bug as of bevy = "0.13.2" Another related issue has a suggestion that an unsupported notice be added for Apple x86_64 Darwin systems running macOS < 13 and XCode < 15.

As this issue does not appear to have much momentum, perhaps it's best to add the disclaimer to the docs and leave it at "won't fix"?

ekalosak commented 7 months ago

Workaround 2

I have a remote desktop setup from macbook to EC2 t2.large ($0.1 / hr) that works pretty well (can use fast compile with DLL, forwards graphics (but not yet audio)) - please see http://ekalosak.github.io for the blog post.

@mockersf should this not be considered "wont fix" and closed as such?