Re: partial GL buffer swap

[Nicolas Silva]

>From an API/feature point of view the partial buffer swap does not sound
like a bad idea, especially since, as Mat said, the OMTC BasicLayers will
need something along these lines to work efficiently.
One thing to watch out for, though, is that it is the kind of fine tuning
that, I suspect, will give very different results depending on the
hardware. On tile based GPUs, doing this without well working extensions
like QCOM_tiled_rendering will most likely yield bad performances, for
example. More importantly I am not sure how much we can rely on these
extensions reliably behaving across the different hardware.
Would we use something like WebGL's blacklisting for this optimization?
I heard that our WebGL blacklisting is a bit of a mess.

Are these the lowest hanging fruits to improve performances?




On Sun, Sep 1, 2013 at 6:53 AM, Matt Woodrow  wrote:

> We actually have code that does the computation of the dirty area
> already, see
>
> http://mxr.mozilla.org/mozilla-central/ident?i=LayerProperties&tree=mozilla-central
> .
>
> The idea is that we take a snapshot of the layer tree before we update
> it, and then do a comparison after we've finished updating it.
>
> We're currently only using this for main-thread BasicLayers, but we're
> almost certainly going to need to extend it to work on the compositor
> side too for OMTC BasicLayers.
>
> It shouldn't be too much work, we just need to make ThebesLayers shadow
> their invalid region, and update some of the LayerProperties comparison
> code to understand the **LayerComposite way of doing things.
>
> Once we have that, adding compositor specific implementations of
> restricting composition to that area should be easy!
>
> - Matt
>
> On 1/09/13 4:50 AM, Andreas Gal wrote:
> >
> > 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.
> >
> > 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
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: partial GL buffer swap

[Matt Woodrow]

We actually have code that does the computation of the dirty area
already, see
http://mxr.mozilla.org/mozilla-central/ident?i=LayerProperties&tree=mozilla-central.

The idea is that we take a snapshot of the layer tree before we update
it, and then do a comparison after we've finished updating it.

We're currently only using this for main-thread BasicLayers, but we're
almost certainly going to need to extend it to work on the compositor
side too for OMTC BasicLayers.

It shouldn't be too much work, we just need to make ThebesLayers shadow
their invalid region, and update some of the LayerProperties comparison
code to understand the **LayerComposite way of doing things.

Once we have that, adding compositor specific implementations of
restricting composition to that area should be easy!

- Matt

On 1/09/13 4:50 AM, Andreas Gal wrote:
>
> 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.
>
> 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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: partial GL buffer swap

[Andreas Gal]

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  wrote:




2013/8/31 Andreas Gal 

>
> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: partial GL buffer swap

[Benoit Jacob]

2013/8/31 Andreas Gal 

>
> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

partial GL buffer swap

[Andreas Gal]

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.


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