Renderer Optimization Round 1 #958

cart · 2020-11-30T02:29:22Z

Its time to start making the renderer fast! This first round is just picking a lot of low hanging fruit.

I ran my tests using the Bevymark example with 10,000 entities.

Starting Performance

// these numbers apply to both moving and non-moving sprites
frame_time    : 0.038522    (avg 0.038975)
fps           : 26.670384   (avg 26.018069)

This PR

// when sprites are static / don't move
frame_time    : 0.017887    (avg 0.017899)
fps           : 55.642482   (avg 55.782829)

// when sprites are moving
frame_time    : 0.023547    (avg 0.022696)
fps           : 41.949551   (avg 42.599443)

Summary of changes

(applied in order, so each item's numbers includes the previous item's changes)

Added change detection to RenderResourceNode, Sprites, and Transforms, which improved performance when those values don't change. (static: 0.0267, dynamic: 0.0336)
Mesh provider system now only updates mesh specialization when it needs to (static: 0.0250, dynamic: 0.0331)
Stop clearing bind groups every frame and remove stale bind groups every other frame. (static: 0.0265)
- this is slightly more expensive on bevymark, but i think its probably still the right thing to do. ill keep an eye on this.
Store unmatched render resource binding results (which prevents redundant computations per-entity per-frame) (static: 0.02411)
Don't send render pass state change commands when the state has not actually changed (static: 0.0179, dynamic: 0.0227)

cart · 2020-11-30T03:06:24Z

Looks like the load_gltf example isn't displaying anything

cart · 2020-11-30T03:10:33Z

Actually that seems unrelated. I'm also hitting the gltf issue on the master branch.

alec-deason · 2020-11-30T07:40:44Z

I'm seeing a problem using this branch. I see a panic on this unwrap https://github.com/cart/bevy/blob/render-opt-round1/crates/bevy_wgpu/src/renderer/wgpu_render_resource_context.rs#L489

The issue seems to be that one part of the infrastructure has a BufferId that has been invalidated because the buffer it references has been resized here: https://github.com/cart/bevy/blob/render-opt-round1/crates/bevy_render/src/render_graph/nodes/render_resources_node.rs#L454

I think this call to write_uniform_buffers should be fixing the BufferId handle that's been removed but it's now behind a Changed filter that didn't used to be there and that is preventing it from getting called: https://github.com/cart/bevy/blob/render-opt-round1/crates/bevy_render/src/render_graph/nodes/render_resources_node.rs#L468

I'm not sure what the relationship is between the RenderResources component that controls the Changed filter and the arrays that are getting resized. But I assume that whatever change it is that causes the array to resize isn't getting caught by the change tracker. If I remove the Changed filter from the query then the panic goes away for me.

alec-deason · 2020-11-30T07:43:08Z

I'm also seeing this panic, which I think is related to this branch as I've never noticed it before but I'm not sure what exactly I'm doing to trigger it. It appears intermittently.

thread 'main' panicked at 'current render pipeline has a layout which is incompatible with a currently set bind group, first differing at entry index 1', /home/alec/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/
wgpu-0.6.2/src/backend/direct.rs:1355:35
stack backtrace:
   0: rust_begin_unwind
             at /rustc/1773f60ea5d42e86b8fdf78d2fc5221ead222bc1/library/std/src/panicking.rs:495:5
   1: std::panicking::begin_panic_fmt
             at /rustc/1773f60ea5d42e86b8fdf78d2fc5221ead222bc1/library/std/src/panicking.rs:437:5
   2: <core::result::Result<T,E> as wgpu::backend::direct::PrettyResult<T>>::unwrap_pretty::{{closure}}
             at /home/alec/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/wgpu-0.6.2/src/backend/direct.rs:1355:35
   3: core::result::Result<T,E>::unwrap_or_else
             at /home/alec/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:825:23
   4: <core::result::Result<T,E> as wgpu::backend::direct::PrettyResult<T>>::unwrap_pretty
             at /home/alec/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/wgpu-0.6.2/src/backend/direct.rs:1355:9
   5: <wgpu::backend::direct::Context as wgpu::Context>::command_encoder_end_render_pass
             at /home/alec/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/wgpu-0.6.2/src/backend/direct.rs:1253:9
   6: <wgpu::RenderPass as core::ops::drop::Drop>::drop
             at /home/alec/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/wgpu-0.6.2/src/lib.rs:2280:13
   7: core::ptr::drop_in_place
             at /home/alec/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:175:1
   8: core::ptr::drop_in_place
             at /home/alec/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:175:1
   9: <bevy_wgpu::renderer::wgpu_render_context::WgpuRenderContext as bevy_render::renderer::render_context::RenderContext>::begin_pass
             at /home/alec/Code/Vendor/bevy/crates/bevy_wgpu/src/renderer/wgpu_render_context.rs:152:9
  10: <bevy_render::render_graph::nodes::pass_node::PassNode<Q> as bevy_render::render_graph::node::Node>::update
             at /home/alec/Code/Vendor/bevy/crates/bevy_render/src/render_graph/nodes/pass_node.rs:207:9
  11: bevy_wgpu::renderer::wgpu_render_graph_executor::WgpuRenderGraphExecutor::execute
             at /home/alec/Code/Vendor/bevy/crates/bevy_wgpu/src/renderer/wgpu_render_graph_executor.rs:73:25
  12: bevy_wgpu::wgpu_renderer::WgpuRenderer::run_graph
             at /home/alec/Code/Vendor/bevy/crates/bevy_wgpu/src/wgpu_renderer.rs:103:9
  13: bevy_wgpu::wgpu_renderer::WgpuRenderer::update
             at /home/alec/Code/Vendor/bevy/crates/bevy_wgpu/src/wgpu_renderer.rs:114:9
  14: bevy_wgpu::get_wgpu_render_system::{{closure}}
             at /home/alec/Code/Vendor/bevy/crates/bevy_wgpu/src/lib.rs:39:9

mockersf · 2020-11-30T08:02:33Z

I'm also seeing the same panic as above randomly

thread 'main' panicked at 'current render pipeline has a layout which is incompatible with a currently set bind group, first differing at entry index 2', /Users/francois/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/wgpu-0.6.2/src/backend/direct.rs:1355:35

most of the time with at entry index 1, got a few times at entry index 2...

Also, I'm having a missing sprite sometimes but always the same, will try to reduce to something minimal

mockersf · 2020-11-30T11:41:38Z

this will not display the sprite, even though it's logged:

use bevy::prelude::*;

fn main() {
    App::build()
        .add_plugins(DefaultPlugins)
        .add_startup_system(setup)
        .add_system(display)
        .run();
}

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

fn display(
    commands: &mut Commands,
    mut first: Local<bool>,
    asset_server: Res<AssetServer>,
    mut materials: ResMut<Assets<ColorMaterial>>,
) {
    if !*first {
        let texture_handle = asset_server.load("branding/icon.png");
        info!(
            "displaying sprite: {:?}",
            commands
                .spawn(SpriteBundle {
                    material: materials.add(texture_handle.into()),
                    ..Default::default()
                })
                .current_entity()
        );
        *first = true;
    }
}

If I put display as a startup system, the sprite is displayed. If I removed the check on first, the sprite is displayed (but a new sprite is created on each frame, hard to know which one is displayed...)

mockersf · 2020-11-30T11:50:28Z

this will crash with thread 'main' panicked at 'current render pipeline has a layout which is incompatible with a currently set bind group, first differing at entry index 1', /Users/francois/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/wgpu-0.6.2/src/backend/direct.rs:1355:35 at the second time spawning text

use bevy::prelude::*;

fn main() {
    App::build()
        .add_plugins(DefaultPlugins)
        .add_startup_system(setup)
        .add_system(display)
        .run();
}

fn setup(commands: &mut Commands) {
    commands
        .spawn(UiCameraBundle::default())
        .with(Timer::from_seconds(1.0, true));
}

fn display(
    commands: &mut Commands,
    mut state: Local<bool>,
    time: Res<Time>,
    mut timers: Query<&mut Timer>,
    texts: Query<Entity, With<Text>>,
    asset_server: Res<AssetServer>,
) {
    for mut timer in timers.iter_mut() {
        timer.tick(time.delta_seconds());

        if timer.just_finished() {
            if *state {
                info!("removing all texts");
                for entity in texts.iter() {
                    commands.despawn_recursive(entity);
                }
            } else {
                info!("spawning texts");

                commands.spawn(TextBundle {
                    style: Style {
                        align_self: AlignSelf::FlexEnd,
                        ..Default::default()
                    },
                    text: Text {
                        value: "text".to_string(),
                        font: asset_server.load("fonts/FiraSans-Bold.ttf"),
                        style: TextStyle {
                            font_size: 60.0,
                            color: Color::WHITE,
                            ..Default::default()
                        },
                    },
                    ..Default::default()
                });
            }
            *state = !*state;
        }
    }
}

crates/bevy_ecs/src/core/world_builder.rs

alec-deason · 2020-11-30T19:34:11Z

@mockersf That example makes sense based on when I'm seeing the panic. I think in my app it only happens when I switch between a state with UI components and one without or vice versa. But it doesn't happen every time the state changes, maybe 50% of the time which makes me think it might be a timing issue.

cart · 2020-12-01T02:47:33Z

A big thanks to everyone for the testing / investigation. I'm diving in now.

cart · 2020-12-01T03:17:13Z

this will not display the sprite, even though it's logged

@mockersf this was a result of us now caching NoMatch bind group lookup results (which prevented future changes to RenderResourceBindings from producing a match). I fixed this in the latest commit. Inserting new bindings now invalidates non-matching results.

cart · 2020-12-01T03:19:32Z

I'm also seeing this panic, which I think is related to this branch as I've never noticed it before but I'm not sure what exactly I'm doing to trigger it. It appears intermittently.

@alec-deason I can trigger it consistently in the bevymark example by spawning in new entities via clicks (as opposed to spawning them all at startup like i did for my benchmarking)

cart · 2020-12-01T03:27:05Z

I'm also seeing this panic, which I think is related to this branch as I've never noticed it before but I'm not sure what exactly I'm doing to trigger it. It appears intermittently.

@alec-deason dropping this commit resolves this issue, so its definitely scoped to that change set.

Lol past @cart was right about it needing a quality check.

@mockersf your text add/remove example is not fixed by reverting that commit, so it comes from somewhere else

cart · 2020-12-01T03:30:39Z

@mockersf the add/remove example panic comes from the "remove stale bind groups" commit. interesting

cart · 2020-12-01T04:11:25Z

@mockersf The add/remove example was broken because RenderResourceBindings isn't made aware when RenderResourceContext removes a "stale" bind group. Therefore even if the BindGroupStatus is "unchanged", we still need to try creating the bind group in case it doesn't exist.

Performance-wise these are our options:

"broken" behavior: ~0.0162
revert the commit entirely: ~0.0180
the "fix": ~0.0173

We're leaving some performance on the table with the "fix", but its still an improvement over the previous behavior.

cart · 2020-12-01T06:16:55Z

@mockersf @alec-deason

Alrighty I think I've fixed all of the problems! Let me know if everything works on your end

…nged

…ck plz)

…has changed

…ResourceBindings

alec-deason · 2020-12-01T07:06:34Z

Something is definitely wrong. It seems like bevy isn't getting the window size right, or maybe isn't handling window resizes correctly.

This is the button example running full screen:

My screenshot tool isn't capturing the cursor for some reason but in this image the cursor is in the middle of the screen, near the lower right hand corner of the gray box. That triggers the button's hover behavior and if you click there the button presses. I assume it's where the button should be.

Resizing the window doesn't seem to effect things the way it normally does, none of the UI resizes or adjusts its layout. I see similar results with other examples and with my application.

alec-deason · 2020-12-01T07:10:51Z

Also I just noticed that the button example is using large amounts of CPU across all my cores, even though it's not doing anything or even visible on the screen right now.

alec-deason · 2020-12-01T07:26:20Z

Never mind. Both problems happen on the current master so they aren't part of this branch.

cart · 2020-12-01T08:09:29Z

Hmm the windowing issue is probably related to #947

cart · 2020-12-01T08:10:32Z

And im planning on optimizing text rendering next, so hopefully that will resolve the button cpu usage issue

alec-deason · 2020-12-01T08:13:22Z

Hmm the windowing issue is probably related to #947

Yeah, that's the commit that caused the regression. I just wrote up an issue: #967

alec-deason · 2020-12-01T19:56:32Z

Ok, having discovered that #967 is an upstream issue I'm back to looking at this. All the issues I was having seem to be resolved. And everything is so much faster!

mockersf · 2020-12-01T21:11:38Z

no more issues for me too 🎉

cart · 2020-12-01T21:17:36Z

Score! Lets merge this.

cart added C-Feature A new feature, making something new possible A-Rendering Drawing game state to the screen labels Nov 30, 2020

ambeeeeee reviewed Nov 30, 2020

View reviewed changes

crates/bevy_ecs/src/core/world_builder.rs Show resolved Hide resolved

cart added 12 commits November 30, 2020 22:26

only update global transforms when they (or their ancestors) have cha…

aa81eca

…nged

only update render resource nodes when they have changed (quality che…

17683dc

…ck plz)

only update entity mesh specialization when mesh (or mesh component) …

7f0e97c

…has changed

only update sprite size when changed

73e0a8e

remove stale bind groups

5bf731d

fix setting size of loading sprites

b5e2afe

store unmatched render resource binding results

e6932e2

reduce state changes

3de2201

cargo fmt + clippy

e9f94df

remove cached "NoMatch" results when new bindings are added to Render…

e3e86d5

…ResourceBindings

inline current_entity in world_builder

832ad38

try creating bind groups even when they havent changed

384204e

cart added 2 commits November 30, 2020 22:26

render_resources_node: update all entities when resized

99b808e

fmt

ea5f41f

cart force-pushed the render-opt-round1 branch from e194eaa to ea5f41f Compare December 1, 2020 06:26

cart merged commit b5ffab7 into bevyengine:master Dec 1, 2020

cart mentioned this pull request Dec 2, 2020

fix changed meshes #984

Merged

b333z mentioned this pull request Dec 3, 2020

load_gltf example not rendering #986

Closed

fopsdev mentioned this pull request Jan 24, 2021

refresh (#1) #1302

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Renderer Optimization Round 1 #958

Renderer Optimization Round 1 #958

cart commented Nov 30, 2020

cart commented Nov 30, 2020

cart commented Nov 30, 2020

alec-deason commented Nov 30, 2020

alec-deason commented Nov 30, 2020

mockersf commented Nov 30, 2020

mockersf commented Nov 30, 2020

mockersf commented Nov 30, 2020

alec-deason commented Nov 30, 2020

cart commented Dec 1, 2020

cart commented Dec 1, 2020 •

edited

Loading

cart commented Dec 1, 2020

cart commented Dec 1, 2020

cart commented Dec 1, 2020 •

edited

Loading

cart commented Dec 1, 2020 •

edited

Loading

cart commented Dec 1, 2020

alec-deason commented Dec 1, 2020 •

edited

Loading

alec-deason commented Dec 1, 2020

alec-deason commented Dec 1, 2020

cart commented Dec 1, 2020

cart commented Dec 1, 2020

alec-deason commented Dec 1, 2020

alec-deason commented Dec 1, 2020

mockersf commented Dec 1, 2020

cart commented Dec 1, 2020

Renderer Optimization Round 1 #958

Renderer Optimization Round 1 #958

Conversation

cart commented Nov 30, 2020

Starting Performance

This PR

Summary of changes

cart commented Nov 30, 2020

cart commented Nov 30, 2020

alec-deason commented Nov 30, 2020

alec-deason commented Nov 30, 2020

mockersf commented Nov 30, 2020

mockersf commented Nov 30, 2020

mockersf commented Nov 30, 2020

alec-deason commented Nov 30, 2020

cart commented Dec 1, 2020

cart commented Dec 1, 2020 • edited Loading

cart commented Dec 1, 2020

cart commented Dec 1, 2020

cart commented Dec 1, 2020 • edited Loading

cart commented Dec 1, 2020 • edited Loading

cart commented Dec 1, 2020

alec-deason commented Dec 1, 2020 • edited Loading

alec-deason commented Dec 1, 2020

alec-deason commented Dec 1, 2020

cart commented Dec 1, 2020

cart commented Dec 1, 2020

alec-deason commented Dec 1, 2020

alec-deason commented Dec 1, 2020

mockersf commented Dec 1, 2020

cart commented Dec 1, 2020

cart commented Dec 1, 2020 •

edited

Loading

cart commented Dec 1, 2020 •

edited

Loading

cart commented Dec 1, 2020 •

edited

Loading

alec-deason commented Dec 1, 2020 •

edited

Loading