Is there API in GL/GLES that can invalidate more than 1 rect simultaneously?
If not and it’s only able to use glInvalidateSubFramebuffer to make 1 rect dirty 1 time, how about the efficiency when continuously call more than 1 glInvalidateSubFramebuffer with different rects using GLES?
Looking for a GL API with the same functionality of eglSetDamageRegionKHR.
Thanks!
I think you might be mis-understanding the point of these APIs.
First, invalidating framebuffers avoids the [mobile] GPU from having to write out buffers of framebuffers that you don’t care about anymore (e.g. the depth buffer, after rendering a frame with depth testing). This allows it to eliminate a lot of writes to the slow DRAM backing the framebuffer.
As far as "sub-"invalidating framebuffers, for some if not all mobile GPU vendors, there’s no benefit. You need to invalidate whole buffers of framebuffers to get a benefit (e.g. link). Example: glInvalidateFramebuffer() / glDiscardFramebufferEXT().
By contrast, the whole set damage thing is meant limit what part of framebuffers need to be redrawn (AFAIK). Different goal with different effects.
1 Like
Thanks!
Is there any GL API can do the same thing as eglSetDamageRegionKHR?
I doubt it. Pure GL doesn’t deal with expose events and damage, as window handling is delegated to a platform-specific window system API.
In GL, you have FBOs (which are offscreen) and “the default framebuffer” (which is often some basic wrapper abstracting rendering to a swap chain image which can be displayed behind-the-scenes later on an OS window). Expose/refresh/damage events are (AFAIK) outside the scope of GL.
1 Like
Thank you very much!
do you know how to call egl API or the wrapper of it in a process that only use GL API now, Thanks!
may i ask that write out buffers from GPU memory to where? driver?but still in GPU memory?same or another one? thanks!
To system memory. The dedicated video memory on a mobile GPU is essentially a cache which only holds a small portion of the framebuffer.
Mobile GPUs typically use tiled rendering, which splits the screen into multiple “tiles”. They only have enough video memory to hold one tile. Rendering commands are captured until it’s necessary to generate the rendered framebuffer. For each tile, the framebuffer contents are copied from system memory to video memory, all rendering commands are executed, ignoring primitives which don’t intersect the tile and rendering into video memory, then the updated video memory is copied out to system memory. Then the process is repeated for the next tile.
If you don’t actually need to preserve the contents of a framebuffer attachment between frames (e.g. because you’re just going to clear it at the start of the next frame), you can “invalidate” the attachment. This tells the implementation that the contents don’t need to be preserved.
1 Like