| 52ea25cf06cef250ec73052611b48556b3fce4d5 |
|
14-Sep-2017 |
Corey Tabaka <eieio@google.com> |
Add shared memory based buffer metadata
This CLs reduces BufferHub CPU consumption by adding asynchronous
state transition so that out-of-process VR composition can run on 2016
pixel devices smoothly. In addition, this CL addresses a couple corner
cases in the existing bufferhub logic, which fixes various blackscreen
issues.
1/ Tracks buffer transition states (gained, posted, acquired, released)
from the client side via atomic shared memory and adds
PostAsync/AcquireAsync/ReleaseAsync/GainAsync with metadata and
fence support.
2/ Adds dequeue order guarantee for buffers enqueued with
dvrWriteBufferQueuePostBuffer.
3/ Synchronous BuffeHub operations are still supported.
4/ Bump up the bufferhubd's soft limit of open file descriptor.
5/ Handle orphaned consumer in acquired state. This is a corner case
that consumer process goes aways (most likely due to a crash) leaving
buffer stuck in acquired state with inconsistent buffer state.
6/ Fixes a race condition for released buffer to be Gain'ed and
Acquire'd when a new consumer is created in released state.
7/ Improve silent consumer queue efficiency: Silent queues no longer
import buffers or receive signals about new buffers and they are
limited to only spawning other consumers and notifications about
producers hanging up.
8/ Modify PDX/UDS channel event signaling to work around epoll
behavior. PDX UDS uses a combination of an eventfd and an epoll set
to simulate the original PDX transport channel events. An odd
behavior discovered in the kernel implementation of epoll was found
that causes the epoll fd to "unsignal" itself whenever epoll_wait()
is called on it, regardless of whether it should still be
pending. This breaks the edge triggerd behavior in nested epoll sets
that channel events depend on. Since this is unlikely to ever be
fixed in the kernel we work around the behavior by using the epoll
set only as a logical OR of two eventfds and never calling
epoll_wait() on it. When polling is required we use regluar poll()
with the eventfds and data fd to avoid the bad behavior in
epoll_wait().
9/ Keep reading data after PDX hangup signal. UDS will signal hangup
when the other end of the socket closes. However, data could still be
in the kerenl buffer and should be consumed. Fix an issue where the
service misses an impulse sent right before the socket is closed.
Bug: 65455724
Bug: 65458354
Bug: 65458312
Bug: 64027135
Bug: 67424527
Test: libpdx_uds_tests
bufferhub_tests
buffer_hub_queue-test
buffer_hub_queue_producer-test
dvr_api-test
Change-Id: Id07db1f206ccf4e06f7ee3c671193334408971ca
/frameworks/native/libs/vr/libdvr/dvr_buffer_queue_internal.h
|
| 638b7f747df50374d1e91c2496da41f293394e19 |
|
08-Sep-2017 |
Jiwen 'Steve' Cai <jwcai@google.com> |
Overhual DvrBuffer and DvrBufferQueue API: Step 1
Adding new APIs:
dvrWriteBufferQueueGainBuffer
dvrWriteBufferQueuePostBuffer
dvrReadBufferQueueAcquireBuffer
dvrReadBufferQueueReleaseBuffer
Those new APIs streamlines DVR buffer operations:
1/ It allows static Dvr{Read,Write}Buffer objects to be statically
allocated with the queue.
2/ Symentric Gain/Post on WriteBufferQueue and Acquire/Release on
ReadBufferQueue.
3/ Use fixed buffer metadata.
4/ This is also a prerequisite to using shared memory based metadata and
async buffer IPC.
More details and discussion at: go/gvr-async-bufferhub
Special note regarding DVR API order in this CL: The new buffer queue
API entries are inserted before new PoseClient API as the PoseClient is
still blocked from being released and the new BufferQueue APIs are
expected to be released sooner than that.
Bug: 65455724
Bug: 65468551
Bug: 65458332
Bug: 65165821
Test: dvr_api-test
Change-Id: Iae8e7787d696d72ebf7457df9f98f4467cd20932
/frameworks/native/libs/vr/libdvr/dvr_buffer_queue_internal.h
|
| 5096c652aa19a501ce28177076de89e58e15b4b3 |
|
09-Aug-2017 |
Marie White <mariewhite@google.com> |
Add api's to dvr_pose to retrieve data from sensord
Bug: 63683612
Test: Manually tested through VrCore cl/164799996.
To retrieve raw data from Tango, added below api's to dvr_api:
- dvrPoseClientGetDataReader
- dvrPoseClientDataCapture
- dvrPoseClientDataReaderDestroy
Note: These changes have already been reviewed in branch
oc-dr1-daydream-dev branch. See change 2729572.
Changes tested on Pixel XL with and without 02 rendering path. Daydream
Home rendering in VR Mode correctly. Pixel functioning as normal.
Change-Id: Ia934d6a1a0b89edfd4408dde19d38e757d44f785
/frameworks/native/libs/vr/libdvr/dvr_buffer_queue_internal.h
|
| 97274870fc8229b507fc71566c0502eb322655cf |
|
21-Jul-2017 |
Jiwen 'Steve' Cai <jwcai@google.com> |
Add dvrReadBufferQueueGetEventFd
We need to expose the read queue's event fd, so that a caller can epoll
on a set of queues' fd for efficient buffer acquisition.
Bug: 62359843
Test: dvrapi-test
Change-Id: I1b9271afed9ee6c6675551402cd3f5a66e98ebe2
/frameworks/native/libs/vr/libdvr/dvr_buffer_queue_internal.h
|
| 0b80155bf5c27b47c160d1904ad442842dc8f0c5 |
|
24-May-2017 |
Jiwen 'Steve' Cai <jwcai@google.com> |
DvrBufferQueue: Add basic event callbacks
Currently, there is no guarantee of thread safty and on which thread
those callbacks are going to be fired.
Three new DVR APIs introduced:
1/ dvrReadBufferQueueSetBufferAvailableCallback
2/ dvrReadBufferQueueSetBufferRemovedCallback
3/ dvrReadBufferQueueHandleEvents
Bug: 36748012
Test: buffer_hub_queue-test, dvr_api-test
Change-Id: I79900c9d205f1808b02400b379c79adb366a1104
/frameworks/native/libs/vr/libdvr/dvr_buffer_queue_internal.h
|
| 656f406fcb0c45fd3c729a513bdd3f353cc6ec1f |
|
22-May-2017 |
Jiwen 'Steve' Cai <jwcai@google.com> |
DvrWriteBufferQueue: support buffer resizing
Currently, the buffer resising is implemented at the C API's
implementation level, i.e. it's a pure client side logic out of the core
BufferHubQueue C++/PDX implementation. The logic is similar to
BufferHubQueueProducer's buffer resizing logic.
Other minor changes:
1/ Use ProducerQueueConfig in DisplaySurface as well, and plumb default
width, height, and format to bufferhubd when a BufferHubQueue is created
through a Display Surface.
2/ Added detailed dvr_buffer_queue comments.
3/ Since we now have more and more logic in dvr_buffer_queue, refactored
Dvr{Read,Write}BufferQueue to be C++-styled class.
Bug: 38324405
Test: buffer_hub_queue_producer-test, buffer_hub_queue-test, dvr_api-test
Change-Id: I7186fc04e84eafda46eca316a94739bb3b5c07ca
/frameworks/native/libs/vr/libdvr/dvr_buffer_queue_internal.h
|