Hi!
I have a question about tiled-rendering.
Wiki says, "Tiled rendering is the process of subdividing (or tiling) a computer graphics image by a regular grid".
As I understand android window is dividing by a grid.
Where is a origin of this grid? (lower left, upper left side, etc...)
If It's depend's on gpu, or driver version how can I actually check this on Android system. May be it depends on Android version?
Thanks for you help!
Hi, thank for you explanation. It is some detail of the problem that I have.
For example application clear screen just once during initialization.
For all frames 2 draws produce: drawing background (2 triangles on the full screen filled blue color (on figure 1.)),
and drawing main geometry (in our case triangle). Main geometry can be moved. On the each frame scissor is used.
Application trace scissor rects between 2 or 3 previous frames (in case if we have double or triple buffering).
Surface is created with value EGL_BUFFER_DESTROYED for attributes EGL_SWAP_BEHAVIOR.
So if I use scissor for full geometry region (see Figure 1) damage region appears. It's actually region of tiles that doesn't covered by scissor rect.
Figure 1. Unaligned scissor rect
In case when scissor a aligned by tiling grid, updated region is correct.
Figure 2. Aligned scissor rect
On picture above you can see that tiling dividing start from the lower left corner (it's true for most devices).
But on some android devices I suppose that surface tiling starts from the upper left corner and application has wrong scissor aligned.
That's why I ask about origin of tiling.
(Using EGL_BUFFER_PRESERVED is too expensive for power consumption
The behavior of EGL_BUFFER_PRESERVED is a nice idea, and in many cases still useful, but many of the theoretical advantages of it are lost in N-buffered systems due to the need to insert this readback of the previous frame's dataMali Performance 3: Is EGL_BUFFER_PRESERVED a good thing?
Mali Performance 3: Is EGL_BUFFER_PRESERVED a good thing?
)
Hi Igor,
You are getting the behaviour I would expect; without EGL_BUFFER_PRESERVE set you are effectively relying on undefined behaviour in the specification. On newer devices which fully support it you may get something like the effect you want using this extension:
https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_swap_buffers_with_damage.txt
... which basically gives a means to do a partial preserve of the pieces which have changed [support for this extension is quite new, and not all operating systems support it fully yet, but I expect that to improve].
Cheers,
Pete
Thank for your answer, Pete.
Using GL_EXT_swap_buffers_with_damage is a good idea. But I'm not sure that power consumption will be acceptable...
This extension may also be of interest:
https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_partial_update.txt