148 lines
7.7 KiB
INI
148 lines
7.7 KiB
INI
#-------------------------------------------------------------------------------
|
|
# 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
|