Confirm
157
edits
Changes
→How Android is using Gralloc
QUESTION: We should understand how Android is using Gralloc, apparently behind an abstraction named SurfaceTexture. How is this designed, and how does this offer a good abstraction of gralloc that works well with vendor-specific lock semantics such as genlock? Do we already have similar abstractions (maybe GonkNativeWindow) ?
SurfaceTexture is a client-server architecture. The SurfaceTextureClient implement EGLNativeWindow, where application render into. When Android hardware UI are used, the SurfaceTextureClient is bound into a EGLSurface, and when applications want to present the buffer it incurs eglSwapBuffers which calls to EGLNativeWindow::queue and EGLNativeWindow::dequeue. Where EGLNativeWindow::queue cause the GraphicBuffer returned to SurfaceTexture side (server side). And EGLNativeWindow::dequeue return a new back buffer for drawing into.
For performance, the client and server side do not pass GraphicBuffer each time queue/dequeue incurred in fact. They refer to the same buffer queue, and just communicate with each other by buffer index.
In Android SurfaceFlinger, the GraphicBuffer bind into GPU is not unlocked explicitly in fact. Since SurfaceTexture runs in sync mode for SurfaceFlinger, the buffer are queued into a queue until it got rendered. When rendering, the SurfaceTexture::updateTexImage are called to update the GraphicBuffer undering the SurfaceTexture. After rendering, the buffer are not used again until next SurfaceTexture::updateTexImage called. Which means Android do not force GPU unlock the buffer, just lock another buffer and return the old buffer until the new buffer comes. (It use fence object to make sure GPU are done with the buffer, and just call glFinish after fence object creation)
