StandardMaterial causes long delays on Firefox with WebGL

[ashivaram23]

Bevy version

0.15.3

Relevant system information

AdapterInfo { name: "Apple M1, or similar", vendor: 4203, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "WebGL 2.0", backend: Gl }

Browser is Firefox 134.0, "WebGL 2 Driver WSI Info" in about:support says it's using CGL

What you did

Open any Bevy project that uses StandardMaterial in Firefox with WebGL. This includes most of the WebGL examples on the Bevy official examples page like https://bevyengine.org/examples/3d-rendering/3d-scene/.

Alternatively, run any Bevy WebGL project that uses a custom material with a large uniform array of large structs:

main.rs

use bevy::{
    prelude::*,
    render::render_resource::{AsBindGroup, ShaderRef, ShaderType},
};

#[derive(Clone, Copy, Default, ShaderType)]
struct LargeStruct {
    a: f32,
    b: f32,
    c: f32,
    d: f32,
    e: f32,
    f: f32,
    g: f32,
    h: f32,
    i: f32,
    j: f32,
    k: f32,
    l: f32,
    m: f32,
    n: f32,
    o: f32,
    p: f32,
}

#[derive(AsBindGroup, Asset, Clone, TypePath)]
struct TestMaterial {
    #[uniform(0)]
    struct_array: [LargeStruct; 200],
}

impl Material for TestMaterial {
    fn fragment_shader() -> ShaderRef {
        ShaderRef::from("test.wgsl")
    }
}

fn main() {
    let mut app = App::new();
    app.add_plugins((DefaultPlugins, MaterialPlugin::<TestMaterial>::default()))
        .add_systems(Startup, setup)
        .run();
}

fn setup(
    mut commands: Commands,
    mut meshes: ResMut<Assets<Mesh>>,
    mut materials: ResMut<Assets<TestMaterial>>,
) {
    commands.spawn((Camera3d::default(), Transform::from_xyz(0.0, 0.0, 10.0)));
    commands.spawn((
        Mesh3d(meshes.add(Cuboid::new(4.0, 4.0, 4.0))),
        MeshMaterial3d(materials.add(TestMaterial {
            struct_array: [LargeStruct::default(); 200],
        })),
    ));
}

test.wgsl

struct LargeStruct {
    a: f32,
    b: f32,
    c: f32,
    d: f32,
    e: f32,
    f: f32,
    g: f32,
    h: f32,
    i: f32,
    j: f32,
    k: f32,
    l: f32,
    m: f32,
    n: f32,
    o: f32,
    p: f32,
}

@group(2) @binding(0) var<uniform> struct_array: array<LargeStruct, 200>;

@fragment
fn fragment() -> @location(0) vec4f {
    return vec4(struct_array[0].a, vec3(1.0));
}

What went wrong

The browser takes several seconds to link the WebGL program. This blocks the main thread and causes a long delay when loading the page or whenever shaders are recompiled.

Additional information

Any browser that uses OpenGL to implement WebGL on macOS runs into this problem. In addition to Firefox, this includes desktop Chrome/Safari whenever the WebGL backend is manually set to OpenGL. Profiling shows that most of the time is spent in calls to glGetActiveUniform or glGetActiveUniformsiv.

What seems to be going on is:

• While linking a WebGL program, the browser has to collect information about each active uniform with calls to glGetActiveUniformsiv and glGetActiveUniform. OpenGL treats each member of a struct as a different uniform resource (see OpenGL introspection documentation), so large arrays of large structs can have a giant number of uniforms to query.
• The StandardMaterial PBR shader accesses clusterable_objects.data in pbr_lighting.wgsl. When storage buffers are unavailable, this is a uniform array of 204 ClusterableObject structs, each with 11 members as defined in mesh_view_types.wgsl. In Firefox's implementation, that makes 2244 uniforms for each of five calls to glGetActiveUniformsiv to check, plus 2244 calls to glGetActiveUniform.
• Parts of a uniform array can be excluded from the list of active uniforms if the shader compiler finds that they're unused, but when the array is in a uniform block, all its uniforms are apparently counted as active (this might be implementation dependent). Naga translates WGSL uniform buffers to GLSL ES uniform blocks, so all members of all 204 entries are queried if any one is accessed.
• The Apple OpenGL implementation is very slow at this for some reason, and the time it takes scales noticeably with the number of uniforms.

If possible, it might help to make space for fewer than 204 entries in clusterable_objects at first if there aren't too many point or spot lights in the scene, then somehow increase the capacity up to MAX_UNIFORM_BUFFER_CLUSTERABLE_OBJECTS if more lights are added at runtime. This might require recompiling shaders, but it would only affect platforms without storage buffer support.

[mockersf]

shaders are known to be long to compile in WebGL2, and block the browser while doing so

[ashivaram23]

I believe this particular delay only happens when using StandardMaterial, only on browsers with OpenGL backends for WebGL, and only because of the couple of lines in the pbr shader where this clusterable_objects array is accessed. Without that length 204 uniform array, I would expect shader link times to go from ~5 seconds of delay to a split second, leading to roughly the same responsiveness as Bevy projects without StandardMaterial and other web game engines/frameworks that also use WebGL.

[john-sharratt]

Opinion: Multithreading will fix this and other related issues as ultimately blocking in WASM (which is highly likely for a number of reasons) starves the main JavaScript engine given WASM effectively runs as an event. Better to offload into other threads and leave the main thread idle for the browser responsiveness, OpenGL commands and IO only - it will fix this problem and many like it, otherwise one is optimizing loads of stuff that one does not need to.

[ashivaram23]

Agreed about the usefulness of browser multithreading for Bevy in general, unfortunately this particular stall happens in a WebGL command (linkProgram/getProgramParameter) as part of canvas rendering and that can only happen on the main thread as far as I know (unless you use an OffscreenCanvas?)

But I think I was wrong about this happening on all browsers with OpenGL backends. Firefox for Android showed a 5-10 second lag too so I just assumed it had the same cause as desktop, but some profiling shows that linkProgram is actually very fast there. Maybe this is just a bug with Apple's deprecated OpenGL implementation.

So the Android browser lag is a completely different issue, and that might indeed benefit from web workers. Chrome for Android, which uses Vulkan on my phone, also has a ~3 second startup lag which is unrelated to this linkProgram problem.

Another thing I found is the KHR_parallel_shader_compile extension, which sounds like it makes the engine compile and link shaders on another thread? But it's not supported on Firefox, which is the main browser that experiences this problem in the first place because it still uses OpenGL to link WebGL programs on Mac while other browsers use Metal. Besides blocking is only half the problem, you'd still have to wait 5-10 seconds to see anything.