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 Igor,
Mali is indeed a tile based GPU. The majority of our GPUs work on a 16x16 pixel tile grid.
Regarding your question about "Android Window", I do not understand what you mean by this, and how it relates to tiled architecture GPUs such as Mali. Could you elaborate?
Also can you explain why you need to know the "origin of the grid" and how this relates to what you are doing?
Kind Regards,
Michael McGeagh
For example, I've created Android Surface which size is w=18px h = 20px. On the picture below shows two cases how
surface could be divided by tiling grid. Application is used glScissor, scissor rect have to be adjusted to match tiling.
Figure 1 shows red pixel that draws on the screen. In the first case scissor rect will be adjusted to match tile with id 1,
in the second case to match tile with id 3.
I suggest that tiling always starts from lower left side, but if it wrong my scissor rect doesn't matches correct tile, which have to be updated.
Figure 1. Different tiled divide
But I think it's depend on android version
Thanks for the additional information.
Please note that a GPU tiling architecture design is completely transparent from both the OS and any applications that run on it.
You should not need to worry about the ordering of, or size of tiles. So I am unsure why you need to know this.
Also note that I am unaware of any display that does not have a multiple of 16pixels in both direction, so there will never not be a full tile at any of the corners of the screen.
Also note that, unless you are rendering your app in immersive mode, you will have an offset from the top status bar and/or bottom menu bar, which could affect your calculations.
Could you explain the reason behind this so we can understand better the problem you are trying to solve?
1080p = 120 * 67.5 tiles, so it's definitely possible to have partial tiles. Which edge has the partial tile may vary, even on the same device (assuming that the partial tile is on the left hand side, rotate your phone 180 degrees, and the partial tile will be on the right hand side).
As mcgeagh mentions all of this is totally transparent to the application; there is no stable correlation between tiles and the application's view of pixels, but you really don't have to worry about it ...
Cheers,
Pete
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?
)
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].
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