Confirmed users
753
edits
Platform/GFX/Gralloc: Difference between revisions
no edit summary
No edit summary |
|||
| Line 62: | Line 62: | ||
GrallocBufferActors are "managed" by IPDL-generated code. When they are created by the above-described protocol, as said above, they are added to the "managee lists" of the LayerTransactionParent on the compositor side, and of the LayerTransactionParent on the content side. | GrallocBufferActors are "managed" by IPDL-generated code. When they are created by the above-described protocol, as said above, they are added to the "managee lists" of the LayerTransactionParent on the compositor side, and of the LayerTransactionParent on the content side. | ||
QUESTION: What then decides when GrallocBufferActors are destroyed and removed from the managee lists? | |||
== Unresolved problems == | == Unresolved problems == | ||
| Line 120: | Line 120: | ||
== Unresolved problems == | == Unresolved problems == | ||
We don't have a great way of un-attaching a gralloc buffer from a GL texture. What we currently do (see GrallocTextureHostOGL::Unlock) is that we issue another fEGLImageTargetTexture2D call to overwrite the attachment by a dummy "null" EGLImage. That is however known to cause performance issues at least on Peak (see {{bug|869696}}). Another approach (that happens to perform better on Peak) is to just destroy the GL texture object (and recreate it every time). But really, we should have a reliable and fast way of releasing the read locks that we are placing on gralloc buffers when we attach them to GL texture objects. We should understand why attaching the dummy "null" EGLImage is slow on the Peak device. | We don't have a great way of un-attaching a gralloc buffer from a GL texture. What we currently do (see GrallocTextureHostOGL::Unlock) is that we issue another fEGLImageTargetTexture2D call to overwrite the attachment by a dummy "null" EGLImage. That is however known to cause performance issues at least on Peak (see {{bug|869696}}). Another approach (that happens to perform better on Peak) is to just destroy the GL texture object (and recreate it every time). But really, we should have a reliable and fast way of releasing the read locks that we are placing on gralloc buffers when we attach them to GL texture objects. QUESTION: We should understand why attaching the dummy "null" EGLImage is slow on the Peak device. | ||
= 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) ? | |||