MSAA in GLES2 slow and breaks Fixed Foveated Rendering #70
Comments
This change avoids any post processing in the case an external texture is used and it also renders directly to the provided external texture. This addresses GodotVR/godot_oculus_mobile#70 and ignores the changes in godotengine#33444 for the android case.
|
@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. |
|
@NeoSpark314 for a straight comparison, what does the performance looks like when |
|
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: While my test branch is at: GPU 2 / 72% |
|
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: Master Branch Fov 4: Hack Branch Fov 0: Hack Branch Fov 4: And here are the screenshots in the same order;
|
|
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)? |
|
@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. |
|
in this case my benchmark from above (the one with Lat 0) reports |
|
@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. |
|
Ok, this is my take on solving this: @NeoSpark314 already tested it out, would be good to get some more feedback. |
|
@BastiaanOlij I've tested the PR, and it works as expected! |
|
Sweet! lets hope it gets merged soon :) |
|
Fixed by godotengine/godot#33518! |
With the recent change in godotengine/godot#33444 turning on MSAA will result in fixed foveated rendeirng not working anymore as performance optimization.
It still gives the artifacts of FFR but not the performance benefit as godot first renders the scene to an internal framebuffer with full resolution and then does a full screen quad to display.
This means in addition a costly framebuffer copy is performed (similar to the problem
for GLES3 in #45).
The reason for the change was a fix in how MSAA works on desktop for GLES2 and to align the implementation to how godot handles MSAA.
The issue here for Oculus Mobile is at the moment only for information as it cannot be resolved inside the plugin. There were some potential solutions discussed with @BastiaanOlij but these would either be very hacky (by falling back only for android on the old behaviour for external textures) or require a breaking change in the ARVR api.
Another suggested solution by @akien-mga was to introduce an additional option called something like external MSAA in the render settings and then not use current the godot MSAA setting. This should also disable any post processing and sounds like a good solution to the problem.
Below are some performance measurements of the current master (the current state in the demo scene needs for 4xMSAA ~GPU level 3-4 to run while the old version was around GPU level 2-3):
MSAA turned off:
4x MSAA:
For reference here is a capture of the now reverted (hacky) fix from godotengine/godot@a3ac7a9
The text was updated successfully, but these errors were encountered: