| #------------------------------------------------------------------------------- |
| # Advanced emulator features |
| #------------------------------------------------------------------------------- |
| |
| # GLPipeChecksum---------------------------------------------------------------- |
| # For every GL call that transfers between host and guest, GLPipeChecksum = on |
| # will compute a checksum consisting of some function of the actual bit vector |
| # corresponding to the GL command, verifying that the same checksum shows up |
| # on both the host and guest. Violations of the checksum (mismatches) result |
| # in an abort() and crash report being sent. |
| # |
| # Currently, the checksum is mainly making sure that the command itself and all |
| # arrays passed through the pipe are of proper length. |
| GLPipeChecksum = on |
| # ------------------------------------------------------------------------------ |
| |
| # GrallocSync------------------------------------------------------------------- |
| # Most apps that display images do so through OpenGL, but there are some apps |
| # that write directly to gralloc color buffers. In our goldfish-driver gralloc |
| # implementation, which represents gralloc color buffers as host OpenGL color |
| # buffers. |
| # |
| # For example, in the camera app, the emulated webcam driver will pull frames |
| # to a gralloc color buffer directly, and then in another thread or process, |
| # the color buffer representing the camera frame preview could be posted |
| # onscreen. |
| # |
| # These operations aren't guaranteed to have their order preserved when arriving |
| # from the guest, and if executed on the host in the wrong order, we could |
| # end up with out of order webcam frames, for instance. |
| # |
| # GrallocSync = on adds synchronization to the host for this use case where apps |
| # directly write to gralloc color buffers and then post them. |
| # Gralloc sync disabled for now because it is making CTS sad. |
| GrallocSync = off |
| # ------------------------------------------------------------------------------ |
| |
| # GLAsyncSwap------------------------------------------------------------------- |
| # OpenGL apps in the guest present their contents indirectly through |
| # SurfaceFlinger. The goldfish driver's implementation of eglSwapBuffers is |
| # based on queuing the finished frame (buffer) to SurfaceFlinger. |
| # SurfaceFlinger then acquires that finished buffer from the OpenGL app, |
| # does the actual posting to the display (which may involve a call in turn |
| # to eglSwapBuffers, esp. if we are not using hardware composer), |
| # and releases the buffer, allowing the OpenGL app to dequeue a fresh |
| # buffer for whatever to draw next. |
| # |
| # The problem is that when we are using host GPU, the rubber meets the road # |
| # in the host not the guest (what the user sees is not due to any concrete |
| # action inside the guest, but due to the host GPU communicating with the host |
| # display), so it's not always clear what a "finished frame" means. In |
| # particular, the frame is not necessarily finished when the buffer is queued |
| # in the guest, depending on host driver quirks. So, posting unfinished or |
| # even older buffers to SurfaceFlinger will result in out of order frames. |
| # |
| # GLAsyncSwap = off pretends this issue doesn't exist and it's up to the host |
| # driver to properly synchronize upon calling rcFlushWindowColorBuffer. |
| # GLAsyncSwap = on uses the host GL driver's fence commands and fence fd's in |
| # the guest in order to have explicit signals of buffer swaps complete. This |
| # preserves frame ordering at a slight performance cost, but the cost is less |
| # than that of other solutions like calling glFinish() on the host. |
| GLAsyncSwap = on |
| # ------------------------------------------------------------------------------ |
| |
| # EncryptUserData--------------------------------------------------------------- |
| # CTS requires that userdata be encrypted, at least for api23 and later. However |
| # for non Google images or older system images, this is not required or not |
| # implemted. Emulator will enable this feature only if the system says it supports |
| # encryption. It is on by default on the host, and according to the current rule, |
| # a feature is only on if both host and guest support it; so it effectively leaves |
| # to guest to decide. |
| EncryptUserData = on |
| # ------------------------------------------------------------------------------ |
| |
| # IntelPerformanceMonitoringUnit------------------------------------------------ |
| # Some CTS tests (mainly SimplePerf) require that the CPU expose some kind of |
| # counters that can be used to measure CPU performance in cycles, |
| # cache hit/miss, etc. |
| # However, the use of this on the vCPU requires that the guest kernel be in |
| # a fairly recent state, otherwise the emulator will kernel panic on startup. |
| IntelPerformanceMonitoringUnit = on |
| # ------------------------------------------------------------------------------ |