OSDN Git Service

Set the outbuf acquire fence after we actually have it.
authorJesse Hall <jessehall@google.com>
Wed, 2 Oct 2013 00:25:20 +0000 (17:25 -0700)
committerThe Android Automerger <android-build@google.com>
Wed, 2 Oct 2013 21:44:42 +0000 (14:44 -0700)
In GLES-only mode, we don't have the outbuf acquire fence until after
GLES composition is done for the frame. We were setting the fence in
HWC's state immediately after dequeueing the buffer from the consumer,
before GLES had started. This fence got passed through HWC and on to
the consumer, so the consumer was reading the buffer before GLES was
done writing to it.

Now we update HWC's state just before set(), when we know we have the
right fence.

Bug: 11000763
Change-Id: Iea9db4c69634c352dc2d600f0bdb6bef2a432636

services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp

index 88ef392..c5a14b0 100644 (file)
@@ -147,6 +147,10 @@ status_t VirtualDisplaySurface::advanceFrame() {
             mFbProducerSlot, fbBuffer.get(),
             mOutputProducerSlot, outBuffer.get());
 
+    // At this point we know the output buffer acquire fence,
+    // so update HWC state with it.
+    mHwc.setOutputBuffer(mDisplayId, mOutputFence, outBuffer);
+
     return mHwc.fbPost(mDisplayId, mFbFence, fbBuffer);
 }
 
@@ -415,7 +419,11 @@ status_t VirtualDisplaySurface::refreshOutputBuffer() {
         return result;
     mOutputProducerSlot = mapSource2ProducerSlot(SOURCE_SINK, sslot);
 
-    result = mHwc.setOutputBuffer(mDisplayId, mOutputFence,
+    // On GLES-only frames, we don't have the right output buffer acquire fence
+    // until after GLES calls queueBuffer(). So here we just set the buffer
+    // (for use in HWC prepare) but not the fence; we'll call this again with
+    // the proper fence once we have it.
+    result = mHwc.setOutputBuffer(mDisplayId, Fence::NO_FENCE,
             mProducerBuffers[mOutputProducerSlot]);
 
     return result;