| #------------------------------------------------------------------------------- |
| # 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. |
| # Disabled by default for now |
| GLAsyncSwap = off |
| # ------------------------------------------------------------------------------ |
| |
| # 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 |
| # ------------------------------------------------------------------------------ |
| |
| # GLDMA------------------------------------------------------------------------- |
| # Video playback can approach 1080p60 and be solid 720p60 if we map guest memory |
| # to host and use it to perofrm color buffer updates, and perform YV12->RGB |
| # on the host as well, in an OpenGL shader. |
| GLDMA = on |
| # ------------------------------------------------------------------------------ |
| |
| # GLESDynamicVersion------------------------------------------------------------ |
| # This feature attempts to detect the maximum supported GLES version depending on |
| # which OpenGL function pointers have been found on the GL libraries used |
| # on the host system. Different platforms / hardware + video driver setups can |
| # have different support. |
| # For example, OS X is not known to support GLES 3.1. |
| # If this feature is set to "off", the max supported GLES version is assumed to |
| # be <= 2 and also depend on the system image only (some images only support ES 1). |
| GLESDynamicVersion = off |
| # ------------------------------------------------------------------------------ |
| |
| # Wifi ------------------------------------------------------------------------- |
| # This feature indicates that the system image and the emulator support Wifi. |
| # When this is enabled the network configuration of the system image will be |
| # significantly different and the emulator will send different network setup |
| # information via RIL. |
| Wifi = on |
| |
| # ForceANGLE-------------------------------------------------------------------- |
| # This feature attempts to default the renderer to ANGLE, but can be itself |
| # overridden by: |
| # -gpu command line argument |
| # UI setting |
| # The override (and others) are done through the UI, so the user is aware |
| # and if the user changes to a setting other than "auto", the user setting |
| # is respected. |
| ForceANGLE = off |
| # ------------------------------------------------------------------------------ |
| |
| # ForceSwiftshader-------------------------------------------------------------- |
| # This feature attempts to default the renderer to Swiftshader. Otherwise, |
| # same behavior as ForceANGLE. |
| ForceSwiftshader = off |
| # ------------------------------------------------------------------------------ |
| |
| # PlayStoreImage --------------------------------------------------------------- |
| # The playstore image has CTS requirements that emulator should check and ensure |
| # Guest image will indicate whether it has it or not; |
| PlayStoreImage = on |
| # ------------------------------------------------------------------------------ |
| |
| # LogcatPipe --------------------------------------------------------------- |
| # The pipe based logcat is meant to replace the 'adb shell logcat' |
| # Guest image will indicate whether it has it or not; |
| LogcatPipe = on |
| # ------------------------------------------------------------------------------ |
| |
| # Hypervisor feature flags. Assumed mutually exclusive. If all flags are off, |
| # then we have: |
| # Mac/Win: HAXM |
| # Linux: KVM |
| # If a flag is on, then attempts are made to detect host support, and if there |
| # is support, then the hypervisor in question is actually used. |
| HYPERV = off |
| HVF = off |
| KVM = off |
| HAXM = off |