search

google / filament

Filament is a real-time physically based rendering engine for Android, iOS, Windows, Linux, macOS, and WebGL2
https://google.github.io/filament/
Apache License 2.0
17.87k stars 1.9k forks source link

When rendering a large model (~7K individual renderables) on a mid range devices (2 to 3 years old) the performance degrades to the point it becomes unusable #8027

Closed mbalajee closed 3 months ago

mbalajee commented 3 months ago

When rendering a large model (~7K individual renderables) on a mid range devices (2 to 3 years old) the performance has been degraded to the point it becomes unusable.

Affected devices: Samsung S6 Tab (2019) Samsung A9+ tab (2023) Samsung S22 Ultra (2022) - Surprised to see low performance on this device OnePlus 6T (2018)

Have no problem on Pixel 8 & 7. Even models with over 10K renderables perform smoothly without any dynamic resolution option.

Recording of a model with 7K renderables on Samsung S6 Tab (same result on all affected devices, worst on OnePlus) in the sample gltf viewer (modified dynamic resolution settings)

pixelflinger commented 3 months ago

Note that the recommended number of draw calls from GPU Vendors is 500 to 1000/frame and you're at 7000+; so you're way past the recommended budget. Regardless, the values you're setting for the Engine.Config are insanely high -- you don't need to go that high; this might hurt performance. Probably using 4MB minCommandBuffer should be way enough. SAme for driverHandleArenaSizeMB, 40MB is crazy.

I think you need to be realistic about what these low-end CPU can render.

mbalajee commented 3 months ago

Thanks for the suggestion, yeah I wasn't sure what's the right value. I was increasing them by 2 MB until I din't see the "mCircularBuffer.size() > requiredSize" panic.

From a bit of a research on how to reduce the draw calls, found that occlusion culling reduces the draw calls by sending only those that are visible to the camera. It looks like there is an open issue for that. Is that still being worked on & will it help reduce the draw calls?

In addition to the large number of renderables, we are also opting in to the extended asset loader which I think duplicates (unshares) the shared vertices thereby increasing the vertex count. This further affects the performance because of increased draw calls.