Performance problem with 4.3 on Native Quest3

[LuckMic]

Tested versions

• Reproducible with v4.3RC1, much better with v4.2.2

System information

Quest3 - Godot_v4.3rc1_win64.exe / OpenXR Vendor plugin 3.0.0 beta 3

Issue description

I made a test project (attached) to show the performance problem. I create a test grid 10x10x15, each grid scene has four visible Meshinstance3D elements with a simple PlaneMesh and a simple StandardMaterial3D (only Albedo color set).

Test 1) Running this on a Quest3 in native mode (OpenXR) with 120 Hz + physics_ticks 120 and the frame per seconds drops down to around 20 fps.

I changed the grid scene to use only one texture instead of the four MeshInstance3D. (Simply remark Test1 and use Test2 part of the main.gd @ beginning of the script)

Test 2) Running this on a Quest3 in native mode (OpenXR) with 120 Hz + physics_ticks 120 and the frame per seconds drops down to around 100 fps.

Both test runs much better on v4.2.2.

Steps to reproduce

Use the attached example project, install der OpenXR vendor plugin and test it with Android SDK 34

Minimal reproduction project (MRP)

GodotPerformanceTestcase.zip

[Saul2022]

120ticks is pretty expensive moreso in vr, for that physics interpolation might solve that when it arrives in the 3d renderer.

Either way , it might be good if you showed your 4.2.2 results.

[akien-mga]

CC @godotengine/xr

Related: https://github.com/godotengine/godot/issues/94856

[LuckMic]

4.3RC1 with gl_comp (Test1/Test2) => 20 fps / 100 fps 4.3RC1 with mobile (Test1/Test2) => 22 fps / 60 fps

4.2.2 with gl_comp (Test1/Test2) => 35 fps / 120 fps 4.2.2 with mobile (Test1/Test2) => 24 fps / 60 fps

Same results with 60 ticks with 4.2.2 and 4.3rc1 - doesn't matter in this test case

[AThousandShips]

To make those results more useful that's: 4.3RC1 with gl_comp (Test1/Test2) => 50 mspf / 10 mspf 4.3RC1 with mobile (Test1/Test2) => 45.45 mspf / 16.67 mspf

4.2.2 with gl_comp (Test1/Test2) => 28.57 mspf / 8.33 mspf 4.2.2 with mobile (Test1/Test2) => 41.67 mspf / 16.67 mspf

So only Test1 has any significant difference between cases I'd say

[LuckMic]

About the project settings / maybe also helpful: I created a new project, used as much as possible to default. I only changed

• OpenXR activated, Shader activated
• Reference space to local
• Environment Additive
• Foveation High/Dynamic
• Hand tracking off
• VRS XR
• Renderer-Method-mobile to gl_comp/mobile
• ETC2 ASTC import active
• Physic-Ticks to 60/120
• Physic-3D separate Thread active

Other settings as default...

[LuckMic]

So only Test1 has any significant difference between cases I'd say

Test2 with 4.3/4.2.2 and gl_comp has also significant difference, but it's not directly visible, because it's capped to 120 fps. With 4.3rc1 and background functions (not part of the test case) the fps are rapidly decreasing to lower values. With 4.2.2 it's much more stable on 120 fps.

[LuckMic]

Is it correct that down scaling actually worsens performance?

I added: get_viewport().scaling_3d_mode = Viewport.SCALING_3D_MODE_FSR get_viewport().scaling_3d_scale = 0.85

Test2 has around 86 fps instead of ~100 fps with BILINEAR with 1.0.

Same result (~86 fps) for SCALING_3D_MODE_FSR2 and SCALING_3D_MODE_BILINEAR with scaling 0.85.

[dsnopek]

Is it correct that down scaling actually worsens performance?

I added: get_viewport().scaling_3d_mode = Viewport.SCALING_3D_MODE_FSR get_viewport().scaling_3d_scale = 0.85

Downscaling requires rendering to an intermediate texture and then copying from that to the texture from OpenXR. While copying from one texture to another is basically free on desktop, it can be expensive on mobile.

So, it's not entirely surprising that downscaling could be slower is some circumstances. It depends on where the bottleneck is: if rendering is the bottleneck, then downscaling can help; but if rendering is already really fast, then the extra work that downscaling is adding could slow things down.