Changes

Jump to: navigation, search

Platform/GFX/Gralloc

703 bytes added, 17:22, 17 May 2013
How Android is using Gralloc
SurfaceTexture is a client-server architecture. The SurfaceTextureClient implements EGLNativeWindow, into which the application renders. When the Android hardware UI is used, the SurfaceTextureClient is bound into a EGLSurface, and when the application wants to present the buffer, it calls eglSwapBuffers which calls to EGLNativeWindow::queue and EGLNativeWindow::dequeue.
Where EGLNativeWindowSurfaceTexture has a buffer queue SurfaceTexture::queue mSlots to store a list of GraphicBuffers owned by this class. SurfaceTextureClient side cache the shared GraphicBuffers in its own mSlots once the buffer allocated. The mechenism here is the client side issues SurfaceTextureClient::dequeueBuffer for new buffer, if there are no enough buffer and the buffer amount is not over the limit, it cause SurfaceTexture::dequeueBuffer occurs which allocate the GraphicBuffer returned to SurfaceTexture side (server side). And EGLNativeWindowafter buffer allocation, the client side will issue SurfaceTexture::dequeue return requestBuffer to get a new back reference to the GraphicBuffer just allocated, and cache the buffer for drawing intoits own mSlots. Then SurfaceTexture can communicate with the buffer index rather then the GraphicBuffer.
For performance, When the client side calls EGLNativeWindow::queue to present the frame from eglSwapBuffers call, SurfaceTextureClient::queue is issued and send the index where the rendered buffer is to server side do not pass GraphicBuffer each time SurfaceTexture::queue/dequeue incurred in fact. They refer Which cause the index queued into SurfaceTexture::mQueue for rendering. SurfaceTexture::mQueue is a wait queue for frame that wants to be rendered. In sync mode, the same buffer queueframe are showed one after another, and just communicate with each other by buffer indexbut may dropped in async mode.
In Android For SurfaceFlinger, the GraphicBuffer bind into GPU is not unlocked explicitly in fact. Since after each time SurfaceTexture runs in sync mode for SurfaceFlinger::queue are issued, the buffer are queued into a queue until it got renderedwill start for next renderloop. When renderingIn each render loop, the SurfaceFlinger calls to SurfaceTexture::updateTexImage are called to update dequeue a frame from SurfaceTexture::mQueue and bind the GraphicBuffer undering the SurfaceTextureinto a texture. After rendering As a result, the buffer are not used again until next SurfaceTexture::updateTexImage called. Which means Android do does not force GPU explicit unlock the buffer, just GraphicBuffer as B2G did now. Since it will lock another next buffer and return the old buffer until the each time new buffer comes. (It And it will use fence object eglCreateSyncKHR/eglClientWaitSyncKHR to make sure GPU the buffer are done with not locked before it returns the GraphicBuffer into the buffer, and just call glFinish after fence object creation)pool.
Confirm
157
edits

Navigation menu