Poor performance rendering points

[jerome-caucat]

Bevy version

0.15.0

Relevant system information

• Machine: laptop XPS 13 9310
• OS: Ubuntu 24.04.2 LTS

`AdapterInfo { name: "Intel(R) Iris(R) Xe Graphics (TGL GT2)", vendor: 32902, device: 39497, device_type: IntegratedGpu, driver: "Intel open-source Mesa driver", driver_info: "Mesa 25.0~git2504031308.ff386e~oibaf~n (git-ff386eb 2025-04-03 noble-oibaf-ppa)", backend: Vulkan }`

What you did

• I am drawing around 300 meshes, each containing between 1 and 200k points, for a total of 4e6 points.
• Each mesh only contain vertex positions, no indices, no normals, with PrimitiveTopology::PointList.
• All the meshes are using the same StandardMaterial and have the NotShadowCaster component:

  StandardMaterial {
      base_color: Color::WHITE,
      unlit: true,
      depth_bias: 0.0,
      alpha_mode: AlphaMode::Opaque,
      fog_enabled: false,
      ..Default::default()
  }

• Adding the NotShadowCaster component was necessary to prevent the shadow passes on the meshes, even though the material is unlit.
• I also tried with a very minimal custom shader, without much improvements.
• I also disabled the vsync with bevy::window::PresentMode::Immediate.

What went wrong

• The GPU Render 3D engine is used at 100%, while the CPU and RAM are barely used.
• The FPS is low: 15 to 20.
• Adding more points slow the app even more, until complete freeze of the app and my displays.

Additional information

• A single draw call for 100k points is listed in RenderDoc with a duration of 1ms.
• The main_opaque_pass_3d is listed in RenderDoc with a duration of 25ms for 4e6 points, over 287 vkCmdDraw.
• The main_opaque_pass_3d, and the duration of the draw calls, seems to be the bottleneck.
• There is not much difference between the dev and release builds.
• I noticed in tracy and RenderDoc that the app still spend some time related to lighting, shadows and fog, but this may be negligible.
• I cannot merge all the points in the same mesh, because the application needs to remove and add batches of points.

RenderDoc	Tracy Frame	Tracy Stats

Considering the amount of points, the framerate seems quite low, the duration of the opaque rendering pass seems excessive. We have another application (not using bevy) that is able to display over 1e8 points without trouble on the same machine.

• Do you have any tips to improve the speed of my application?
• Or to help me debug the problem?
• Do you think drawing triangles instead of points could help?

[alice-i-cecile]

I would avoid using StandardMaterial if you're only rendering points. You should be able to save a great deal of work by using a more minimal custom material.

[alice-i-cecile]

@IceSentry (one of our rendering SMEs) is also very curious about the performance on the 0.16 release candidate (or 0.16 itself, depending on how long it's been since I left this comment). We've made some pretty serious rendering performance gains there, but I'm personally skeptical of how much it helps you in particular, as a lot of the gains are moving work to the GPU, and you appear to be GPU bound currently.

[JMS55]

Having a mesh with a giant list of points is going to be... Expensive. And bevy has no means of reusing GPU memory when you change an asset iirc, so changing the mesh/points would be reallocating an entire new buffer.

Ideally you want to write your own rendering code that does a single draw, and uses vertex pulling (reading from a storage buffer) to get the position of each point.

Then if you're still GPU bound, you need to start looking into bypassing the GPU's fixed function hardware altogether. There's a recent paper on using a Nanite-like culling, LOD, and software rendering scheme for rendering massive point clouds for instance https://dl.acm.org/doi/pdf/10.1145/3543863.

[jerome-caucat]

I would avoid using StandardMaterial if you're only rendering points. You should be able to save a great deal of work by using a more minimal custom material.

@alice-i-cecile Thank you for the suggestion, but I already tried with a very simple shader, without improvements:

Simple Shader

#import bevy_pbr::mesh_functions::{get_world_from_local, mesh_position_local_to_clip}

struct MyMaterial {
    color: vec4<f32>,
};
@group(2) @binding(0) var<uniform> material: MyMaterial;

struct Vertex {
    @builtin(instance_index) instance_index: u32,
    @location(0) position: vec3<f32>,
};

struct VertexOutput {
    @builtin(position) clip_position: vec4<f32>,
};

@vertex
fn vertex(vertex: Vertex) -> VertexOutput {
    var out: VertexOutput;
    out.clip_position = mesh_position_local_to_clip(
        get_world_from_local(vertex.instance_index),
        vec4<f32>(vertex.position, 1.0),
    );
    return out;
}

@fragment
fn fragment() -> @location(0) vec4<f32> {
    return material.color;
}

[...] about the performance on the 0.16 release [...]

@alice-i-cecile I can give a try to the v0.16.0-rc.3. I'll let you know.

Ideally you want to write your own rendering code that does a single draw, and uses vertex pulling (reading from a storage buffer) to get the position of each point.

@JMS55 Thank you, I'll look into that.

[JMLX42]

Having a mesh with a giant list of points is going to be... Expensive. And bevy has no means of reusing GPU memory when you change an asset iirc, so changing the mesh/points would be reallocating an entire new buffer.

@JMS55 I might misunderstand this statement, but we are not trying to update the buffer of the point clouds. The buffers are const 99% of the time (100% for now actually). We have 250 to 500 buffer of points. And we expect to be able to make 250 to 500 draw calls at interactive speed. It's like we're rendering 250 to 500 meshes. But those meshes are points, not triangles.

Ideally you want to write your own rendering code that does a single draw, and uses vertex pulling (reading from a storage buffer) to get the position of each point.

@JMS55 we have an existing "raw" renderer that does what I described above and it works just fine. A few hundred draw calls is fine, even on (Web) mobile platforms.

Then if you're still GPU bound, you need to start looking into bypassing the GPU's fixed function hardware altogether. There's a recent paper on using a Nanite-like culling, LOD, and software rendering scheme for rendering massive point clouds

@JMS55 rendering 5 to 10 million points is - AFAIK - nowhere near "massive" point clouds.

[JMS55]

In that case you're probably just running into "Bevy's rendering is slow". Will probably be better in 0.16, but still might not be as fast as you're expecting since you're familiar with writing your own renderer.

[JMLX42]

In that case you're probably just running into "Bevy's rendering is slow". Will probably be better in 0.16, but still might not be as fast as you're expecting since you're familiar with writing your own renderer.

@JMS55 so it's expected for Bevy to be limited to 250 draw calls on a modern laptop? That can't be right. That's what 10 yo mobile devices with OpenGL ES 2 do.

In any case we will investigate and help wherever we can.