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/libpdx_uds/private/uds/ipc_helper.h
|
adfc42ead3921f94339372ffb561bc3e8d7f3c86 |
|
07-Sep-2017 |
Alex Vakulenko <avakulenko@google.com> |
Reduce the number of Send requests over UDS per IPC invocation We sent up to 3 separate send requests over a socket. Now combine then into one sendmgs() to improve performance and thread scheduling. This improves PDX/UDS performance by up to 2x in some cases. Bug: 65379030 Test: Sailfish works normally. Was able to run VR apps. Change-Id: I00734d2c3f06d7d42b089569a8cc11c2273a1b7f
/frameworks/native/libs/vr/libpdx_uds/private/uds/ipc_helper.h
|
e41826ac301b9afad1cbfe59c57e27f2495be968 |
|
02-May-2017 |
Alex Vakulenko <avakulenko@google.com> |
libpdx_uds: Always create channel sockets in the server process Whenever a client connects to PDX service endpoint, the connected socket was being used as the channel connection. This makes it difficult to ensure that the socket has the appropriate SELinux label applied. Changed the implementation to make sure that the actual channel socket pair is created in one place in the server process. The new Endpoint::CreateChannelSocketPair() is now being used to create the channel sockets when an incoming connection is accepted and when PushChannel request is received. The newly created channel socket is sent to the client in response to connection request. Bug: 37646189 Test: Device boots. CubeSea launches. Change-Id: Id3158484aeb18007f18b279afc60613076f80f14
/frameworks/native/libs/vr/libpdx_uds/private/uds/ipc_helper.h
|
d618b567630d347be0929ea25ce6c68921005ed6 |
|
17-Apr-2017 |
Alex Vakulenko <avakulenko@google.com> |
libpdx_uds: Fix send/receive over socket to handle signal interrupts Previous implementation of send/receive didn't account for the fact that send/receive operation might be interrupted by a signal and transfer fewer bytes than requested. Fix this by repeatedly calling send/recv until all the requested data is transferred over sockets. Also added a number of unit tests for send/receive functions. Bug: 37427314 Test: `m -j32` succeeds for Sailfish. `libpdx_uds_tests` pass on device Change-Id: Ib8f78967af3c218d9f18fb3dfe8953c35800540b
/frameworks/native/libs/vr/libpdx_uds/private/uds/ipc_helper.h
|
09aa736ee6136787b18807d7ab459feba23cec04 |
|
06-Apr-2017 |
Alex Vakulenko <avakulenko@google.com> |
libpdx_uds: Fix RPC channel ID allocation to not recycle values as often The value of channel ID for PDX service on UDS transport was actual file descriptor value for the data socket. Since channels are open and closed constantly, it is quite often that channel ID is being reused immediately, so it is almost impossible to use `cid` as unique identifier for objects being passed around. Instead, we now use monotonically growing channel ID value. To prevent the possibility of using channel ID as the socket FD and vice versa, changed all helper functions that used to take socket_fd as an int to explicitly use BorrowedHandle which disables implicit conversion from int (and hence makes it impossible to mistakenly pass in the channel ID). Bug: 37082296 Test: `m -j32` succeeds for sailfish-eng Ran libpdx_uds_tests on the device -> all pass Device boots and CubeSea and VrHome render correctly with vr_flinger Change-Id: Ibb8dfee4d6c3f4b6120c0b6e20a253f1b9307c19
/frameworks/native/libs/vr/libpdx_uds/private/uds/ipc_helper.h
|
f0a7bd033941e26e380232a0515e903cf8e678e5 |
|
01-Apr-2017 |
Alex Vakulenko <avakulenko@google.com> |
pdx: Rework error reporting when transfering file and channel handles There is a lot of confusion about reporting errors when passing file and channel handles over PDX transport between client and service. Methods like Message::PushFileHandle return an integer which means both a file handle reference value (if positive) and a possible error code (if negative). But file handles could contain negative values too (when they are empty). This is used frequently when passing buffer fences around (when a fence is not being used, its fd is set to -1). This results in a special case of when PushFileHandle is called with a file handle with value of -1, the return value is actually "-errno" which becomes dependent on a global state (errno is not set by PushFileHandle itself in case file handle value is negative) and results in unpredicted behavior (sometimes errno is 0, sometimes its >0). Cleaned this all up by using Status<T> everywhere we used an int to pass value payload along with possible error code. Now the semantics of the calls are more clear. Bug: 36866492 Test: `m -j32` for sailfish-eng succeeds Ran unit tests on device (pdx_tests, libpdx_uds_tests, bufferhub_tests, buffer_hub_queue-test, buffer_hub_queue_producer-test), all pass Ran CubeSea, NativeTreasureHunt and Ithaca on Sailfish with vrflinger enabled, was able to use controller and screen rendered correctly. Change-Id: I0f40c3f356fcba8bc217d5219a0ddf9685e57fd7
/frameworks/native/libs/vr/libpdx_uds/private/uds/ipc_helper.h
|
e4eec20f6263f4a42ae462456f60ea6c4518bb0a |
|
27-Jan-2017 |
Alex Vakulenko <avakulenko@google.com> |
Add DaydreamVR native libraries and services Upstreaming the main VR system components from master-dreamos-dev into goog/master. Bug: None Test: `m -j32` succeeds. Sailfish boots and basic_vr sample app works Change-Id: I853015872afc443aecee10411ef2d6b79184d051
/frameworks/native/libs/vr/libpdx_uds/private/uds/ipc_helper.h
|