-
Notifications
You must be signed in to change notification settings - Fork 34
Costly Full FrameBuffer Copy in GLES3 Renderer #45
Comments
Indeed, this has always been an issue for VR. While on one side people will want to be able to do some amount of post effects requiring this copy anyway, that we already take the render buffer and copy this to the final output through a lens distortion shader just seems wasteful. It can be more then one depending on the post effects used. A more efficient way would be to skip the post effect step in Godot and either accept that as a limitation of the platform (on the Quest you're already trying to minimize unneeded overhead) or see if the platform allows some post effects in the lens distortion shader. The problem for other VR platforms Godot has to support is that for say desktop VR you still want to output to screen, something we have to keep in mind if we implement support for this in the core. The final problem that needs to be resolved if we make it optional to skip the post effects is that the render buffer that Oculus wants us to create, and the render buffers that Godot needs in order to do its rendering properly, don't match up. Godot adds a number of extra effect buffers and requires the main color target to be a RGBA16F based buffer, not all platforms support. Things will change radically for Vulkan anyway so it may be smart to wait and see where that ends up and then decide how we want to move forward with the new render pipeline. |
From my perspective I think waiting is also probably the best option. When I opened the issue I thought that using GLES3 would be the preferred choice for Mobile/Quest (assuming that OpenglES 3.0/3.1 features would allow better performance). But even with the option to disable post processing I see there are too many performance pitfalls due to the tiled render architecture for mobile with the current GLES3 renderer. |
@NeoSpark314 Can you elaborate on the performance pitfalls you're seeing with the GLES3 renderer. |
From what I remember at the moment (I stopped using GLES3 after I opened this issue :-) the main issue I saw with GLES3 is that there are many options that require additional full screen passes that are extremly expensive (mostly due to bandwidth): auto exposure, glow, SSAO, and screen space reflections that can easily be turned on in gles3; All in all just the demo project with no additional post processing enabled is already close to maxing out the GPU with GLES3 (gpu running at level 4); while in GLES2 it runs comfortably at level 2: From my current experience I would list the following performance suggestions at the moment:
|
Currently the GLES3 renderer seems to be setup to always perform a full frame copy after rendering even when no post processing is enabled (It then just does the Srgb conversion).
Below is a screenshot of a renderdoc trace that shows the frame copy for each eye that happens via a full screen quad.
On tile-based GPU architectures this is very expensive and according to this talk: https://www.youtube.com/watch?v=CQxkE_56xMU&feature=youtu.be&t=2426 it takes 2.5ms on an Oculus Quest (from the total of 13.8ms available for 72hz).
Ideally there would be an option to avoid post processing and the buffer copy completely even for a GLES3 renderer as in most cases it is way too expensive; but to solve this it would probably require change in the GLES3 render architecture.
A sideeffect of this fullscreen copy is that the 4x multisampling set here:
godot_oculus_mobile/src/common.h
Line 75 in 3639380
is not affecting the final result and probably only costs bandwidth when the full screen quad is rendered to an MSAA target.
Screenshot of the GLES3 render doc trace (of two cubes rendered at the controller position)
![renderdoc_gles3](https://user-images.githubusercontent.com/1610621/64078843-4db5a000-cce0-11e9-873c-c66be892f95a.png)
The text was updated successfully, but these errors were encountered: