Age | Commit message (Collapse) | Author |
|
The scenario is the following:
1. Process1 creates a T1 with a new buffer, release callback, and
transaction callback. The release callback is stored locally in
mReleaseBufferCallbacks so it only lives in Process1.
2. Process2 creates a T2 with a transaction callback
3. When T1 and T2 are merged, the SC from T1 end up getting the
transaction callbacks from T2. SC will end up with multiple transaction
callbacks
4. In BufferStateLayer, we only added mPreviousReleaseCallbackId to one
transaction callback. There's a chance the release callback would only
end up on the transaction callback for Process2.
Process2 doesn't have the data about the callback since it was only
stored in Process1. When Process2 gets the transaction callback, it
will not handle the releaseCallbackId since it doesn't know what release
callback it represents. Process1 will get a transaction callback, but will
not contain a releaseCallbackId.
To fix, add releaseBufferEndpoint that is set when the client calls
setBuffer. This is used in SurfaceFlinger to recognize which listener
was the one that set the buffer so it can send the release information
to the correct listener.
Test: ReleaseBufferCallback_test
Bug: 193565751
Change-Id: I534fbde2a54608c2e30852e48dc0c75c86b22525
|
|
Now that we only write to current state from the main thread
we can actually just write directly in to drawing state and
avoid copying current to drawing state on each frame. simpleperf
on bouncing ball indicates this was saving around 8% CPU or so
per frame. As a next target we will eliminate the remaining work
in doTransaction and eliminate the doTransaction pass.
Test: Existing tests pass. simpleperf
Bug: 186200583
Change-Id: I59b75747d7371b3ffe870129c8be100c7daa6c4e
|
|
Allocate HAL virtual display and generate HAL/GPU virtual display ID in
SF rather than CE. This centralizes the HAL vs. GPU decision as a first
step in isolating display configuration (e.g. hotplug, modeset) to be a
distinct stage from invalidate/refresh.
Rework SF backend hooks for screen capture. Plumb the PhysicalDisplayId
to be mirrored by the virtual display to Composer::createVirtualDisplay.
This enables the ARC backend to know which display to mirror (instead of
making assumptions about the layer stack) or error out if not mirroring
(previously done through maybeAllocateDisplayIdForVirtualDisplay), such
that SF falls back to creating a GPU virtual display.
Bug: 182939859
Bug: 129481165
Test: Enable overlay display and toggle HAL/GPU
Test: libsurfaceflinger_unittest
Test: libcompositionengine_test
Change-Id: I209b245966e544d5ff55d5d118140cfcfa85db15
Merged-In: I209b245966e544d5ff55d5d118140cfcfa85db15
|
|
Revert submission 14199598-revert-14086921-renderengine-external-tex-QJNBWQMQEU
Reason for revert: Prepare for relanding
Reverted Changes:
I01e65a7f4:Revert "Update WaylandRenderSurface to accomodate ...
I7d58118c1:Revert "Update Readback VTS to align with RenderEn...
I1501890f4:Revert "Add ExternalTexture class into RenderEngin...
Added the following fixes:
1. CachedSet renders to intermediate texture variable rather than
mTexture directly, since mTexture is not guaranteed to be nonnull.
2. Add null check when setting new buffer in BLAST.
Bug: 185524947
Bug: 180767535
Test: builds, boots
Test: librenderengine_test
Change-Id: I52ea82e24336b496d996bbe3e445db0affe1abb8
|
|
sc-dev
|
|
Revert submission 14086921-renderengine-external-tex
Reason for revert: Potential culprit for b/185361988
Reverted Changes:
I7796764e2:Update WaylandRenderSurface to accomodate interfac...
I13904eec4:Update Readback VTS to align with RenderEngine int...
I222c71e6e:Add ExternalTexture class into RenderEngine interf...
Change-Id: I1501890f4861a3df7ce273f1fe2ccdb275e2632c
|
|
|
|
ExternalTexture is an RAII structure that wraps raw GraphicBuffers that
are passed into RenderEngine. ExternalTexture's role is to help with
managing GPU resources of GraphicBuffers by mapping buffers into
textures, EGLImages, or AutoBackendTextures depending on the
RenderEngine backend. Under the hood, mapExternalTextureBuffer and
unmapExternalTextureBuffer (renamed from cacheExternalTextureBuffer and
unbindExternalTextureBuffer respectively) are used to help tie
resource management to the ExternalTexture lifetime.
The main motivation for this is that currently managing buffer
lifecycle has historically been errorprone and caused memory leaks, so
this improves code health.
As part of this:
* mapExternalTextureBuffer and unmapExternalTextureBuffer
are now protected methods, and are never called outside of RenderEngine
with the exception of creating and destroying ExternalTextures.
* Because GLESRenderEngine's output buffers are cached differently from
Skia RenderEngine, if there are output-only buffers then disable the
mapExternalTextureBuffer calls whenever GLESRenderEngine is used.
* Custom RAII classes in the Planner and in BufferLayerConsumer are now
removed since they're subsumed by ExternalTexture
* RenderSurface now controls its own management of ExternalTextures in a
small queue
* cleanFramebufferCache is now unimplemented for Skia, because
ExternalTextures are now deleted whenever a RenderSurface is deleted.
Bug: 180767535
Test: libsurfaceflinger_unittest
Test: libcompositionengine_test
Test: librenderengine_test
Test: Simulate virtual displays
Test: Screen reotation
Test: Movie playback on Google TV
Test: Force GPU composition
Test: screenshot
Change-Id: I222c71e6e1c67485cdeac49e2cb829289af9efec
|
|
There are no users left
Bug: 168505645
Change-Id: I81725bf3c0ef4704e9da25da9a75854b4f172885
|
|
Currently BLAST clients use the TransactionCompleted callbacks to
determine when to release buffers. The TransactionCompleted callback
is overloaded. For transactions without buffers, the callback is
called when the transaction is applied on the server. If the
Transaction contains one or more buffers, the callback is called when
all the buffers are latched and ready to be presented. If we have
multiple buffers on multiple transactions, where one or more buffers
maybe dropped, the pending callbacks are called together. This may
delay signaling the client when a buffer can be released.
To fix this, we introduce a new buffer release callback that is
called as soon as a buffer is dropped by the server or when a new
buffer has been latched and the buffer will no longer be presented.
This new callback provides a graphic bufferid to identify the buffer
that can be released and a release fence to wait on.
BlastBufferQueue has been switched to use this new callback. Other
BLAST users continue to use the existing callback.
Test: go/wm-smoke
Test: atest ReleaseBufferCallbackTest
Bug: 178385281
Change-Id: Idd88e4994e543443198a5a8cfa0e3f5f67d5d482
|
|
Since the BLASTBQ adapter removed the BQ path from SurfaceViews to
SurfaecFlinger, FrameLifecycle is completely broken as it works only for
BQ so far. This change adds FrameLifecycle coverage to BLAST buffers
that send dequeueTime along with the Transaction.
Bug: 176931912
Test: TransactionFrameTracerTest
Test: Take a trace of any game and make sure Frame Lifecycle events show
up.
Change-Id: I1429c86f2890c3ff8e5a06d6136df0282cf439ea
|