[Mesa-dev] Question about EGL_KHR_partial_update implementation
harish.krupo.kps at intel.com
Tue Jul 3 01:40:10 UTC 2018
Thanks for probing about this.
Qiang Yu <yuq825 at gmail.com> writes:
> Hi Harish,
> I want to implement EGL_KHR_partial_update for lima mesa driver and find you
> worked on Android/Wayland support for it:
> So I have some question about it:
> your implementation seems to depend on platform (Android, wayland) support,
> for example call native_window_set_surface_damage() in Android implementation.
> What's the purpose of it, tell the Android SurfaceFlinger to redraw the damage
> region? And is this damage region the "surface damage" or "buffer
> damage" metioned
> in the EGL_KHR_partial_update?
The idea was to provide the damage regions so that the compositor
(Hardware Composer) could use them to optimize its composition path.
> To my understand this extension should only depend on the driver support instead
> of platform support while the EGL_KHR_swap_buffers_with_damage is the opposite:
I always wondered why android didn't implement this in its EGL-Layer if
all it had to do was to send the rectangles to the compositor.
Now that I think about it, I too feel that it should be implemented by the driver.
Looking at the deqp test case for partial_udpate, it also looks like the
intension was for the rendering to be restricted to only those rectangles.
Side question: We could also send the damage to the compositor?
> For lima implementation, I want to use the damage region (buffer
> damage) provided
> by EGL_KHR_partial_update to skip rendering of un-damaged region when
> eglSwapBuffersXXX. And tell damage region (surface damage) to compositor should
> be left to eglSwapBuffersWithDamageKHR provided by
How do you plan to implement it?
More information about the mesa-dev