RibirX/Ribir

Ribir panics when opening any program on macOS

TheRacecar opened this issue · 7 comments

TheRacecar commented

Problem
Ribir panics when opening any Ribir program on macOS.

Error message:

thread 'main' panicked at /Users/****/.cargo/registry/src/index-crates.io-6f17d22bba15001f/wgpu-0.20.0/src/backend/wgpu_core.rs:2996:5:
wgpu error: Validation Error

Caused by:
    In Device::create_render_pipeline
      note: label = `Color triangles pipeline`
    Internal error in ShaderStages(FRAGMENT) shader: Metal: Compilation failed:

program_source:144:3: error: size of constant buffer cannot exceed 65536
, constant type3& mask_layers [[buffer(0)]]
  ^

Steps To Reproduce
Steps to reproduce the behavior:

  1. Create a new Cargo project on macOS and add Ribir as a dependency
  2. Copy in the code below (however any code works fine)
use ribir::prelude::*;

fn main() {
    App::run(fn_widget! {
        @Text { text: "Hello, world!" }
    });
}
  1. Run using cargo run.

Expected behavior
The application to compile and open regularly without any issues.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment:

  • Ribir version: 0.3.0-alpha.5
  • Rust version: nightly
  • OS, if relevant: macOS 10.15 Catalina
M-Adoo commented

Thank you for reporting this issue! It appears we may be exceeding the buffer size limit.

I've tested on two macOS devices with newer versions (Sonoma 14.5), and both are working fine with 0.3.0-alpha.5 and the latest master branch.

Unfortunately, I don't have access to a macOS 10.15 Catalina device to reproduce the issue. Could you provide more details about the problem?

The panic message indicates that the error occurs with wgpu 0.20.0. However, Ribir 0.3.0-alpha.5 uses wgpu version 0.19.0. Are you running the examples program from the master branch? If possible, could you try running the latest master branch to see if the issue is resolved?

TheRacecar commented

If possible, could you try running the latest master branch to see if the issue is resolved?

I created a new Cargo project with the below toml:

[package]
name = "testing"
version = "0.1.0"
edition = "2021"

[dependencies]
ribir = { git = "https://github.com/RibirX/Ribir", version = "0.3.0-alpha-5" }

which I added from running cargo add with the Github repository link.

When running the program again, the same error appears.

The panic message indicates that the error occurs with wgpu 0.20.0. However, Ribir 0.3.0-alpha.5 uses wgpu version 0.19.0. Are you running the examples program from the master branch?

Yes, I am running the examples program from the master branch.

When I add the 0.3.0-alpha.5 version to the cargo.toml with ribir = "0.3.0-alpha.5", another 4 errors appear:

   Compiling ribir_text v0.3.0-alpha.5
   Compiling ribir_gpu v0.3.0-alpha.5
error[E0432]: unresolved import `ribir_algo::ShareResource`
 --> /Users/****/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ribir_text-0.3.0-alpha.5/src/font_db.rs:7:22
  |
7 | use ribir_algo::{Sc, ShareResource};
  |                      ^^^^^^^^^^^^^ no `ShareResource` in the root

error[E0432]: unresolved import `ribir_algo::ShareResource`
 --> /Users/****/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ribir_gpu-0.3.0-alpha.5/src/gpu_backend/textures_mgr.rs:9:5
  |
9 | use ribir_algo::ShareResource;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^ no `ShareResource` in the root

error[E0050]: method `begin_frame` has 1 parameter but the declaration in trait `begin_frame` has 2
  --> /Users/****/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ribir_gpu-0.3.0-alpha.5/src/gpu_backend.rs:96:18
   |
96 |   fn begin_frame(&mut self) {
   |                  ^^^^^^^^^ expected 2 parameters, found 1
   |
   = note: `begin_frame` from trait: `fn(&mut Self, ribir_painter::Color)`

error[E0050]: method `draw_commands` has 5 parameters but the declaration in trait `draw_commands` has 4
   --> /Users/****/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ribir_gpu-0.3.0-alpha.5/src/gpu_backend.rs:102:5
    |
102 | /     &mut self, viewport: DeviceRect, commands: Vec<PaintCommand>, surface: Color,
103 | |     output: &mut Self::Texture,
    | |______________________________^ expected 4 parameters, found 5
    |
    = note: `draw_commands` from trait: `fn(&mut Self, guillotiere::euclid::Rect<i32, PhysicUnit>, Vec<PaintCommand>, &mut <Self as PainterBackend>::Texture)`

Strangely, when adding the aforementioned package ribir_algo to the toml with version 0.3.0-alpha.5, the same errors appear.

This happens with all the prerelease versions.

M-Adoo commented

The compiler error you're seeing is in the latest alpha version. It'll be fixed in the next alpha release. For now, use version 0.2.0.

About the panic issue on macOS 10.15, I don't have a machine with this OS right now. But, I'll try to find one and check the issue by next week. Or, I might try to reproduce it on a CI machine.

Thanks again, and I'll keep you updated on the progress.

M-Adoo commented

@TheRacecar, I apologize for the inconvenience. The macOS 10.15 Actions runner image is being deprecated and be removed by 8/30/22, which means I can't reproduce the issue on my side to fix it.

The problem seems to be that we're requiring the uniform buffer size to be 65536 (64K), which exceeds the limit of your device.

I'd be happy to assist you in resolving this issue. Here's what you can do:

You can assign a smaller number, like 16384 (16K), to uniform_bytes at this location.

Then, try running the examples on your device.

If this works, please print the value of limits.max_uniform_buffer_binding_size, which is the original value assigned to uniform_bytes. We need to understand why we're querying a limit that exceeds the actual limit of the device.

TheRacecar commented

You can assign a smaller number, like 16384 (16K), to uniform_bytes at this location.

This worked, and the examples (in my case, the Wordle game) worked properly with no errors.

If this works, please print the value of limits.max_uniform_buffer_binding_size, which is the original value assigned to uniform_bytes.

The number outputted was 3758096384.

M-Adoo commented

Do you have dual graphics cards in your system? It's possible that we're querying the limits from one card, but creating the buffer on the other.

TheRacecar commented

I do not have dual graphics cards in my system, however the problem may be is that it could be querying the buffer limit from the graphics card, but creating the actual buffer on the CPU's internal graphics.

If you are interested, here are the specs:

iMac (Retina 4K, 21.5-inch, 2017)
Processor: 3.4 GHz Quad-Core Intel Core i5
Memory: 8 GB 2400 MHz DDR4
Graphics: Radeon Pro 560 4 GB