Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash: Buffer size 17179869184 is greater than the maximum buffer size #736

Open
nicoburns opened this issue Nov 7, 2024 · 4 comments
Open
Labels
bug Something isn't working

Comments

@nicoburns
Copy link
Contributor

nicoburns commented Nov 7, 2024

When trying to render https://wpt.live/css/css-flexbox/flexbox-paint-ordering-002.xhtml with Blitz (tested with Blitz commit d02253d), I am getting the following error:

wgpu error: Validation Error

Caused by:
  In Device::create_buffer
    Buffer size 17179869184 is greater than the maximum buffer size (268435456)

Stack trace:

stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: wgpu::backend::wgpu_core::default_error_handler
   3: core::ops::function::Fn::call
   4: <wgpu::backend::wgpu_core::ContextWgpuCore as wgpu::context::Context>::device_create_buffer
   5: <T as wgpu::context::DynContext>::device_create_buffer
   6: wgpu::Device::create_buffer
   7: vello::wgpu_engine::ResourcePool::get_buf
   8: vello::wgpu_engine::WgpuEngine::run_recording
   9: vello::Renderer::render_to_texture
  10: vello::Renderer::render_to_surface
  11: blitz_renderer_vello::renderer::Renderer<W>::render
  12: dioxus_native::window::View<Doc>::resume
  13: <dioxus_native::application::Application<Doc> as winit::application::ApplicationHandler<dioxus_native::waker::BlitzEvent>>::resumed
  14: winit::platform_impl::macos::event_loop::map_user_event::{{closure}}
  15: winit::platform_impl::macos::event_handler::EventHandler::handle_event
  16: winit::platform_impl::macos::app_state::ApplicationDelegate::dispatch_init_events
  17: winit::platform_impl::macos::app_state::ApplicationDelegate::app_did_finish_launching

To reproduce, run:

cargo run --release -p readme https://wpt.live/css/css-flexbox/flexbox-paint-ordering-002.xhtml

I'm not surprised that wgpu fails to allocate a buffer that's >1GB. The question is why Vello is trying to allocate such a big buffer. The scene is relatively simple, and I am only trying to render it at 800x600 resolution (the command above actually multiplies that by the system's scale factor, but this bug also reproduces with a hardcoded scale factor of 1).

This test is specifically testing overlapping content, so it may be that that's triggering the bug in Vello.

@nicoburns nicoburns added the bug Something isn't working label Nov 7, 2024
@DJMcNab
Copy link
Member

DJMcNab commented Nov 8, 2024

Hmm, this is strange. The buffer specifically appears to be sized at exactly $$2^{34}$$ bytes (i.e. $$2^{32}$$ u32 words?)

Can you determine which buffer is being created? I don't have the bandwidth to prioritise this, but if you can work out where the number is coming from, that would be very helpful.

@matthunz
Copy link

matthunz commented Nov 16, 2024

Getting the same in https://github.com/actuate-rs/actuate when painting using a non-trivial number of elements in the Scene. I'm also appending each "widget"'s Scene to its parent, so maybe combining Scenes is the issue?

Edit: Or just from overflowing the size of the surface region? 🤔

@waywardmonkeys
Copy link
Contributor

@matthunz If you can do this under a debugger and see what command is being run in the recording and anything about what is happening at that level?

Your theory about scene appending being related is interesting.

@waywardmonkeys
Copy link
Contributor

@matthunz As we get closer to wanting to do a 0.4 release, it would be great if you could help us track this down!

@waywardmonkeys waywardmonkeys added this to the Vello 0.4 Release milestone Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants