MSAA in GLES2 slow and breaks Fixed Foveated Rendering about godot_oculus_mobile HOT 12 CLOSED

@BastiaanOlij @akien-mga this is too high of a cost for a clean implementation. Unless the external msaa option is quick to add, can we revert to the 'hacky' fix for now on Android.

from godot_oculus_mobile.

@NeoSpark314 for a straight comparison, what does the performance looks like when lat is set to 0?

from godot_oculus_mobile.

I just reran the test with my test branch and lat 0; the difference is not that significant as in my first test; I need to check if I made some mistake somewhere:
Current Master Reports GPU 2 / 77%:

11-09 15:14:19.153   989  1076 I VrApi   : FPS=72,Prd=45ms,Tear=0,Early=71,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=1/2,1344/414MHz,OC=FF,TA=0/0/E0,SP=N/N/F,Mem=1554MHz,Free=1220MB,PSM=0,PLS=0,Temp=27.0C/0.0C,TW=2.68ms,App=9.46ms,GD=0.00ms,CPU&GPU=10.51ms,LCnt=1,GPU%=0.77,CPU%=0.06(W0.10)

While my test branch is at: GPU 2 / 72%

11-09 15:16:00.561  6225  6285 I VrApi   : FPS=72,Prd=45ms,Tear=0,Early=72,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=1/2,1344/414MHz,OC=FF,TA=0/0/E0,SP=N/N/F,Mem=1554MHz,Free=1216MB,PSM=0,PLS=0,Temp=28.0C/0.0C,TW=2.69ms,App=8.73ms,GD=0.00ms,CPU&GPU=9.85ms,LCnt=1,GPU%=0.72,CPU%=0.05(W0.09)```

from godot_oculus_mobile.

I could not find a mistake in my measurement above so far. I made a renderdoc trace and in the case of the master branch the full screen quad is rendered (but suspiciously cheap... maybe there is no copy performed in this setup...)

But the other problem is still very easily reproducible with Fixed Foveated Rendering (Fov). I made a Spatial Material with 3 textures:

Master Branch Fov 0:

11-09 15:56:48.880  2459  2527 I VrApi   : FPS=68,Prd=31ms,Tear=0,Early=0,Stale=72,VSnc=1,Lat=0,Fov=0,CPU4/GPU=4/4,2304/670MHz,OC=FF,TA=0/0/E0,SP=N/N/F,Mem=1295MHz,Free=1230MB,PSM=0,PLS=0,Temp=34.0C/0.0C,TW=1.96ms,App=13.72ms,GD=0.00ms,CPU&GPU=21.65ms,LCnt=1,GPU%=1.00,CPU%=0.02(W0.05)

Master Branch Fov 4:

11-09 15:55:57.580 32471 32536 I VrApi   : FPS=66,Prd=31ms,Tear=0,Early=0,Stale=72,VSnc=1,Lat=0,Fov=4,CPU4/GPU=4/4,2304/670MHz,OC=FF,TA=0/0/E0,SP=N/N/F,Mem=1554MHz,Free=1233MB,PSM=0,PLS=0,Temp=34.0C/0.0C,TW=1.95ms,App=15.23ms,GD=0.00ms,CPU&GPU=22.17ms,LCnt=1,GPU%=0.98,CPU%=0.03(W0.05)

Hack Branch Fov 0:

11-09 15:49:59.186 21900 21966 I VrApi   : FPS=65,Prd=31ms,Tear=0,Early=0,Stale=72,VSnc=1,Lat=0,Fov=0,CPU4/GPU=4/4,2304/670MHz,OC=FF,TA=0/0/E0,SP=N/N/F,Mem=1804MHz,Free=1246MB,PSM=0,PLS=0,Temp=33.0C/0.0C,TW=3.12ms,App=15.31ms,GD=0.00ms,CPU&GPU=22.71ms,LCnt=1,GPU%=1.00,CPU%=0.02(W0.05)

Hack Branch Fov 4:

11-09 15:54:27.988 30050 30113 I VrApi   : FPS=72,Prd=31ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=4,CPU4/GPU=1/2,1344/414MHz,OC=FF,TA=0/0/E0,SP=N/N/F,Mem=1554MHz,Free=1242MB,PSM=0,PLS=0,Temp=34.0C/0.0C,TW=2.72ms,App=9.84ms,GD=0.00ms,CPU&GPU=11.00ms,LCnt=1,GPU%=0.80,CPU%=0.10(W0.17)

And here are the screenshots in the same order;

from godot_oculus_mobile.

General question I'm wondering about now: is GPU utilization actually the right performance indicator for the bandwidth cost of a full screen copy (and that supposedly 2.5ms seconds it costs as mentioned here: https://www.youtube.com/watch?v=CQxkE_56xMU&feature=youtu.be&t=2426)?

from godot_oculus_mobile.

@BastiaanOlij @akien-mga The fact that it breaks FFR is IMO reason enough to revert PR #33444.

@NeoSpark314 According to this ovrmetrics blog post, GPU utilization is useful but app GPU time might be a better metrics to measure the performance impact.

from godot_oculus_mobile.

in this case my benchmark from above (the one with Lat 0) reports App=9.46ms vs App=8.73ms;
still not the 2.5ms claimed in the video; but slightly higher increase from a relative point of view compared to the gpu utilization. I might try the Snapdragon profiler later; but I can't get it to run on my Linux machine.

from godot_oculus_mobile.

@m4gr3d, the problem is that it's more then just a hack, MSAA was simply broken due to the introduction of external textures, we can't leave broken features in place just because there is one use case where it half worked, especially seeing Quest users are only a small group of the total Android users that may be effected by the hack.

For me the ideal solution is where we enhance the plugin system to provide a properly setup FBO instead of just the texture when we have the plugins supply the render targets, and in doing so completely disable both pre and post processing done in Godot. But that is a 4.0 enhancement imho best combined with other changes we want to do to the GDNative XR Interface..

An in between solution for 3.2 would be to just add a switch to enable MSAA on the external textures FBO and make sure we don't use Godots own MSAA solution (as that just creates buffers that remain unused and result in even more hacky code in the rendering loop to ignore Godots MSAA when we're using an external texture). I also vote to make that a setting on the viewport instead of a project setting. That way this feature can also be used to optimize desktop VR (the Oculus Rift S will benefit from this improvement too) while we can still use MSAA for anything rendered to screen if we chose to.

It will also allow us to evaluate the impact on GLES3 and start thinking about how we want to solve this properly in Godot 4.0 when Vulkan support is done. Quest, Rift S and OpenXR will all need to have a solid way to provide the render target Godot renders into replacing Godots own internal render target.

from godot_oculus_mobile.

Ok, this is my take on solving this:

godotengine/godot#33518

@NeoSpark314 already tested it out, would be good to get some more feedback.

from godot_oculus_mobile.

@BastiaanOlij I've tested the PR, and it works as expected!

from godot_oculus_mobile.

Sweet! lets hope it gets merged soon :)

from godot_oculus_mobile.

Fixed by godotengine/godot#33518!

from godot_oculus_mobile.