Experiments and calculations show that the previous SOC we had for Flatfish (tablet) could only fill about 3x the frame buffer size at 60fps. Without culling occluded layers the homescreen would only pan at 25 FPS or so. So yes, this is very much motivated by concrete hardware problems. Tablets tend to have underpowered GPUs in comparison to the screen resolution. We will need all three. We have to cull occluded layers, we should use partial buffer swap, and we should use 2D composition hardware since in certain cases it can bypass writing to the frame buffer, saving that bandwidth.
Also, I am a bit skeptical of your math. You are using the maximum fill rate of adreno. In practice fill rate might be further limited by the memory used. We have seen substantial differences in memory bandwidth between devices. We can ask our hardware friends for an explanation why this is the case. I am also working on a set of CSS benchmarks to measure fill rate (CSS allows us to measure both, 2D compositor and the GPU). That should shed some light on this variance between devices. Andreas Sent from Mobile. On Aug 31, 2013, at 17:40, Benoit Jacob <jacob.benoi...@gmail.com> wrote: 2013/8/31 Andreas Gal <andreas....@gmail.com> > > Soon we will be using GL (and its Windows equivalent) on most platforms to > implement a hardware accelerated compositor. We draw into a back buffer and > with up to 60hz we perform a buffer swap to display the back buffer and > make the front buffer the new back buffer (double buffering). As a result, > we have to recomposite the entire window with up to 60hz, even if we are > only animating a single pixel. > Do you have a particular device in mind? Knowing whether we are fill-rate bound on any device that we care about is an important prerequisite before we can decide whether this kind of optimization is worth the added complexity. As an example maybe showing why it is not out of hand obvious that we'd be fill-rate bound anywhere: the ZTE Open phone has a MSM7225A chipset with the "enhanced" variant of the Adreno 200 GPU, which has a fill-rate of 432M pixels per second (Source: http://en.wikipedia.org/wiki/Adreno). While that metric is hard to give a precise meaning, it should be enough for an order-of-magnitude computation. This device has a 320x480 screen resolution, so we compute: (320*480*60)/432e+6 = 0.02 So unless that computation is wrong, on the ZTE Open, refreshing the entire screen 60 times per second consumes about 2% of the possible fill-rate. On the original (not "enhanced") version of the Adreno 200, that figure would be 7%. By all means, it would be interesting to have numbers from an actual experiment as opposed to the above naive, abstract computation. For that experiment, a simple WebGL page with scissor/clearColor/clear calls would suffice (scissor and clearColor calls preventing any short-circuiting). Benoit > > On desktop, this is merely bad for battery life. On mobile, this can > genuinely hit hardware limits and we won't hit 60 fps because we waste a > lot of time recompositing pixels that don't change, sucking up memory > bandwidth. > > Most platforms support some way to only update a partial rect of the frame > buffer (AGL_SWAP_RECT on Mac, eglPostSubBufferNVfor Linux, setUpdateRect > for Gonk/JB). > > I would like to add a protocol to layers to indicate that the layer has > changed since the last composition (or not). I propose the following API: > > void ClearDamage(); // called by the compositor after the buffer swap > void NotifyDamage(Rect); // called for every update to the layer, in > window coordinate space (is that a good choice?) > > I am using Damage here to avoid overloading Invalidate. Bike shedding > welcome. I would put these directly on Layer. When a color layer changes, > we damage the whole layer. Thebes layers receive damage as the underlying > buffer is updated. > > The compositor accumulates damage rects during composition and then does a > buffer swap of that rect only, if supported by the driver. > > Damage rects could also be used to shrink the scissor rect when drawing > the layer. I am not sure yet whether its easily doable to take advantage of > this, but we can try as a follow-up patch. > > Feedback very welcome. > > Thanks, > > Andreas > > PS: Does anyone know how this works on Windows? > ______________________________**_________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/**listinfo/dev-platform<https://lists.mozilla.org/listinfo/dev-platform> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
