[Interest] 60FPS and FBO

[Thomas Senyk]

On Fri, November 30, 2012 13:33:35 Samuel Rødal wrote:
> On 11/27/2012 10:39 AM, Thomas Senyk wrote:
> > On Tue, November 27, 2012 10:12:58 Samuel Rødal wrote:
> >> On 11/26/2012 05:50 PM, Thomas Senyk wrote:
> >>> Hi,
> >>> 
> >>> the context of this is mail is:
> >>>    - scenegraph
> >>>    - FBO based effects
> >>>    (plain shader-effects, qtgraphicaleffects, qt3d)
> >>>    - embedded hardware / opengl es 2.0
> >>> 
> >>> I've noticed that on a lot of embedded systems the FPS drops rather
> >>> drastically (e.g. from 60 to 30 with one effect, from 30 to 10-15 with
> >>> two
> >>> effects) when using FBO based effects.
> >>> 
> >>>     ... even simple effects, sometimes even if they have 'visible:
> >>>     false'
> >>> 
> >>> Is this somewhat expected?
> >>> It does sound like a vsync vs. fbo problem ... doesn't it?
> >>> Is this a fault/bug in the embedded opengl drivers?
> >> 
> >> As Florian also commented I've noticed that the FPS very easily drops to
> >> 30 when not using the threaded renderer.
> >> 
> >> But even if that's not the case, I guess FBOs can be heavy on the GPU,
> >> especially if they're large (screen sized) as it basically implies
> >> another full-screen render pass, plus some synchronization overhead
> >> depending on the architecture; when rendering to the main framebuffer
> >> some GPUs have a deep pipeline of several frames being in flight at the
> >> same time, this pipeline might not be possible to utilize for FBOs since
> >> the result of rendering to the FBO is typically used quite immediately
> >> for rendering into another FBO or the main framebuffer. An interesting
> >> experiment might be to do double buffering by keeping two FBOs and only
> >> using the FBO that was rendered to during the last frame as a source
> >> during the current frame. That would mean the FBO content and non-FBO
> >> content would not be completely in sync though (unless you used
> >> predictive timing for the FBO content or introduced extra latency). It
> >> would have significant implications for memory use and its effectiveness
> >> would depend highly on the driver and GPU architecture.
> >> 
> >> I would be surprised if rendering to an FBO involved a vsync, since
> >> there's no eglSwapBuffers() call involved in the process. You simply
> >> bind an FBO, render to it, release it, and use it as a texture (this
> >> step is where you get the synchronization hit).
> >> 
> >>> Did anyone ever had a setup, using one or multiple FBO based effects did
> >>> still result in 60fps? (as it should be for simple(!) effects?)
> >> 
> >> At least on the Raspberry Pi I believe I've gotten 60 fps performance
> >> out of ShaderEffects on ShaderEffectItems or layers. Not sure they were
> >> fullscreen though.
> >> 
> >> There are some general tricks you can use to get better performance when
> >> using ShaderEffects:
> >> 
> >> If you're applying effects on a sub-tree that is not animating, and the
> >> ShaderEffect involves some heavy fragment program computation (such as a
> >> nice blur effect), you can trade memory for performance by caching the
> >> result of the ShaderEffect in a texture. This can be done simply by
> >> setting "layer.enabled: true" on the ShaderEffect. Careful though, if
> >> the sub-tree that is a source for the shader effect _is_ animating, this
> >> will instead cause a drop in performance since the layer would need to
> >> be updated each frame.
> >> 
> >> In some cases you might get away with applying the effect at a lower
> >> level in the Item hierarchy, for example instead of applying an effect
> >> on a Rectangle that contains a rotating Image, separate the effect into
> >> two components, one that applies to the Rectangle and one that applies
> >> to the Image, cache the result of applying the effect to the image with
> >> the "layer.enabled: true", and apply the rotation animation on the
> >> effect instead of the source Image. This assumes that the effect is
> >> rotation independent though, for example if it's doing a pure color
> >> transform (gray-scale or sepia etc). Of course, even better would be to
> >> have a PNG with the effect pre-applied :)
> >> 
> >> In general, shader effects or not, you can always use "layer.enabled:
> >> true" on non-animating sub-trees to trade memory for performance.
> 
> And of course, if two recursive effects can be combined into one, that's
> usually the right thing to do (although it might break encapsulation a bit).
> > You should consider writing a blog entry about all the possibilities and
> > risks of FBO ;) 'Using FBO based effects - Doing it right' :)
> 
> Maybe, if I get the time :) Would be useful to do some benchmarking etc
> as well in conjunction with the article to show the actual benefits.

Sounds good!
Qt5 is nearly done, you should get the time! ;)

> 
> --
> Samuel