Confirm
753
edits
Changes
→Gralloc buffers locking
= Gralloc buffers locking =
Gralloc buffers need to be locked before they can be accessed for either read or write. This applies both to software accesses (where we directly address gralloc buffers) and to hardware accesses made from the GL.
== The lock mechanisms used by Gralloc buffers (non Mozilla-specific) ==
How gralloc buffer locking works, varies greatly between drivers. While we only directly deal with the gralloc API, which is the same on all Android devices (android::GraphicBuffer::lock and unlock), the precise lock semantics vary between different vendor-specific lock mechanisms, so we need to pay specific attention to them.
* On Android >= 4.2, a standardized fence mechanism is used, that should work uniformly across all drivers. We do not yet support it.
* On Qualcomm hardware pre-Android-4.2, a Qualcomm-specific mechanism, named Genlock, is used. We explicitly support it. More on this below.
* On non-Qualcomm, pre-Android-4.2 hardware, other vendor-specific mechanisms are used, which we do not support (see e.g. {{bug|871624}}).
=== Genlock ===
Official genlock documentation can be found in Qualcomm kernel sources: [https://github.com/gp-b2g/gp-peak-kernel/blob/master/Documentation/genlock.txt genlock.txt].
In a nutshell, with genlock,
* Write locks are completely exclusive, both with any other write lock and also with any read lock
* Read locks are non-exclusive, reference-counted, and recursive. This means that a single caller may issue N read locks on a single gralloc buffer handle, and then issue N unlocks to release the lock.
Genlock is implemented in the driver. The kernel GL driver is able to lock and unlock directly. Typically, it will place a read lock on any gralloc buffer that's bound to a texture it's sampling from, and unlock when it's done with that texture.
== How we lock/unlock Gralloc buffers ==
=== Drawing to Gralloc buffers ===
When (on the content side) we want to draw in software to a gralloc buffer, we call ShadowLayerForwarder::OpenDescriptor() in ShadowLayerUtilsGralloc.cpp. This calls android::GraphicBuffer::lock(). When we're done, we call ShadowLayerForwarder::CloseDescriptor() in the same file, which calls android::GraphicBuffer::unlock().
This is generally done by TextureClientShmem.
=== Drawing from Gralloc buffers (binding to GL textures) ===
When (on the compositor side) we want to draw the contents of a gralloc buffer, we have to create an EGLImage with it (see GLContextEGL::CreateEGLImageForNativeBuffer), and create a GL texture object wrapping that EGLImage (see GLContextEGL::fEGLImageTargetTexture2D).
This is generally done by GrallocTextureHostOGL.
== 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 overwrite the attachment by a dummy "null" EGLImage. That is however known to cause performance issues at least on Peak (see {{bug|869696}}). The other approach (that happens to perform better on Peak
