bridge.conf

#
# Remix Bridge Settings
#

#
# Client Settings
#

# When set to true then the bridge client attempts to load a vanilla
# dxvk dll without RTX extensions named d3d9vk_x86.dll, and expects
# that the file is present in the current client working directory.
# This setting is only useful for testing and troubleshooting purposes,
# and should not be changed unless you know what you are doing!
#
# Supported values: True, False

# client.useVanillaDxvk = False


# Sets up the same exception handler on the client side that we use
# on the server side to catch exceptions and write out a dump file
# if the server crashes. This is disabled for the client by default
# because it may conflict with exception handlers setup by games or
# game launchers, as there can only be a single handler.
#
# Supported values: True, False

# client.setExceptionHandler = False


# Enables hooking the client directly into message pump functions
# for input capture. If mouse or keyboard do not work in a game
# this may be a way to get it working, but due to the volume of
# incoming messages this should only be turned on when needed.
# Defaults to being turned off.
#
# Supported values: True, False

# client.hookMessagePump = False


# Set to True, if a game uses SetWindowsHook with WH_CALLWNDPROC
# or WH_GETMESSAGE for the message processing. For example,
# some games use such hooks to read inputs, so enabling this
# option will correctly ignore the inputs when Remix GUI is enabled.
# Defaults to being turned off.
#
# Supported values: True, False

# client.overrideCustomWinHooks = False


# Enables DirectInput message forwarding to the Remix Runtime UI.
# In some titles DirectInput messages may interfere with Windows
# input message causing Remix UI input to misbehave. If this happens
# in a game you are trying to remix, try disabling DirectInput
# message forwarding.
#
# Supported values: True, False

# client.DirectInput.forwardMessages = True


# Enables DirectInput exclusive input. Only affects fullscreen modes.
# When Remix UI input misbehaves in fullscreen mode, try disabling
# DirectInput exclusive input.
#
# Supported values: True, False

# client.DirectInput.disableExclusiveInput = False


# Forces windowed mode even for games that try to launch in fullscreen,
# which is useful for troubleshooting and debugging purposes. Turned
# off by default.
#
# Supported values: True, False

# client.forceWindowed = False


# Sets the process-default DPI awareness to system-DPI awareness, so the
# app can properly handle the DPI scaling. Most games need this feature
# so enable by default.
# But this could crash in headless windows, which need to be turned off
#
# Supported values: True, False

# client.enableDpiAwareness = True


#
# Server Settings
#

# When set to true then the bridge server attempts to load a vanilla
# dxvk dll without RTX extensions named d3d9vk_x64.dll, and expects
# that the file is present in the current server working directory.
# This setting is only useful for testing and troubleshooting purposes,
# and should not be changed unless you know what you are doing!
# 
# Supported values: True, False

# server.useVanillaDxvk = False


# When the bridge server shuts down after the client process has
# exited due to a crash or other unexpected event it will try to shut
# itself down gracefully by disabling the bridge and letting the
# command processing loop exit cleanly. However, in certain cases this
# may never happen because the command loop itself might be in a
# deadlock waiting on another thread to complete, and therefore the
# server would never exit.
# These shutdown values are used to give the server a certain amount
# of time before force quitting the application. This way we ensure
# that there is never a zombie process left behind.
#
# Supported values: 
# shutdownTimeout: Any integer from 1 to 4,294,967,295
# shutdownRetries: Any integer from 0 to 4,294,967,295

# server.shutdownTimeout = 100
# server.shutdownRetries = 50


#
# Global Settings
#

# Sets the size in bytes that is allocated as shared memory between
# the bridge client and server components. This memory is used to
# efficiently share chunks of arbitrarily sized data like textures
# or anything else stored and accessed by D3D9 APIs.
# Defaults to 96 MB of RAM for client to server communication and
# 32 MB for server responses back to the client, which should be a
# good starting point for most cases.
# Making this too big can cause issues because memory has to
# be allocated in one consecutive chunk, so depending on available
# system RAM there may not be a large enough chunk available to
# satisfy the request. Also this shared memory needs to fit within
# the 2GB maximum which most 32-bit games have available unless
# they were compiled with large address option.
# Making this value smaller should be fine as long as the size is
# not smaller than the largest chunk of data that needs to be read
# or written by D3D9. If this happens at runtime it will be detected
# and an error will be written to the log file.
#
# Supported values: Any number in Bytes from 1 to 4,294,967,295.

# clientChannelMemSize = 100663296
# serverChannelMemSize = 33554432


# Configures the size of the circular buffers which are used internally
# to keep track of the commands and data being sent between the bridge
# client and server components.
# The values are not bytes, but number of items per circular buffer.
# For the command buffer this is a fixed size (currently 12 Bytes)
# since the command object has a fixed size, so we can guarantee that
# we will have enough memory to store the entire queue size if needed.
# For the data buffer this value is somewhat arbitrary, since the
# amount of data can be of variable size, so we don't actually know how
# many data items we can fit into the available memory at once.
# However, since we consolidate all data sent for a command into a
# single item there shouldn't be more data items than command items in
# the queue at any given time.
# Making these numbers too small may lead to data starvation depending
# on whether the bridge client or server component read/write data
# faster than the other side.
# Setting this value to 1 effectively means that each command sent by
# the client has to be read by the server before the next command can
# be sent, and forces the client and server to run in lockstep.
# Default values are 3000 for both the command and data queue size for
# client to server communication, and 10 commands and 25 data queue
# items for server responses back to the client. The response queues
# can be smaller since these responses are typically processed
# synchronously and don't queue up for long.
#
# Supported values: Any number between 1 and 100,000

# clientCmdQueueSize = 3000
# clientDataQueueSize = 3000
# serverCmdQueueSize = 10
# serverDataQueueSize = 25


# If enabled sets the maximum latency in number of frames the bridge
# client can be ahead of the server process before it blocks and waits
# for the server to catch up. We want this value to be rather small so
# the two processes don't get too far out of sync to prevent issues
# like the command buffer filling up entirely, causing the client to
# block on some arbitrary command rather than at the same call. We
# typically want to block on the D3D9 Present() call, so we sync and
# block on full frames only.
# If disabled then the max frames setting will be ignored and the
# bridge client will never block on it.
#
# Supported enabled values: True, False
# Supported max frames values: Any number between 0 and 255

# presentSemaphoreEnabled = True
# presentSemaphoreMaxFrames = 3


# Toggles between waiting on and triggering the command queue semaphore
# for each command separately when batching is off compared to waiting
# for it only once per frame, used in conjunction with the Present
# semaphore above. Fewer semaphore calls should give us better
# performance, so this is turned on by default.
# Note: Command batching is not fully implemented yet, so this setting
# has no effect until this note is removed.
#
# Supported values: True, False

# commandBatchingEnabled = False


# For the D3D9 bridge to work only those API calls are relevant that
# create objects, write to memory, or otherwise change the D3D9 state
# in a way the bridge server component needs to be aware of. By default
# we skip any read-only calls that are only used to read back the state
# or content of an object on the client side, and therefore serve no
# purpose on the server side. However, for debugging and troubleshooting
# it can sometimes be helpful to check state values and verify that the
# content being read matches on both the bridge client and server. By
# toggling this setting we also send read-only calls to the server.
# Default is false.
#
# Supported values: True, False

# sendReadOnlyCalls = False


# The current D3D9 bridge implementation covers a majority of the most
# used D3D9 API calls, but we have not reached full coverage yet. If
# an API is used that is not fully implemented yet we will write the
# first occurrence of that call to the log file to identify gaps that
# still need to be closed. In most cases it is only useful to log those
# D3D9 API calls that have not been implemented on the server side yet,
# but by toggling this you will get the first usage of all D3D calls
# logged, including the implemented ones. This can be useful for
# troubleshooting purposes if the order in which certain APIs were
# called is relevant. Default is false.
#
# Supported values: True, False

# logAllCalls = False


# The bridge client and server inter-process communication (IPC) relies
# on sending a lot of commands and data from the client to the server
# constantly. During normal operation this works fine and as expected,
# however if the client or server run into an issue we may end up in a
# situation where one of the components is no longer able to read or
# write commands/data. Instead of waiting forever and ending up in a
# deadlock we use timeout and retry values. These values strike a good
# balance between not waiting too long while still being resilient
# enough against blips that could cause intermittent timeouts.
# If the server encounters a timeout caused by the client not sending
# any more commands, then it will automatically exit after having
# exhausted all its retry attempts.
# If the client encounters a timeout caused by the command buffer
# being filled up from the server not processing commands (either
# quickly enough or at all) or because the server stopped processing
# commands for other reasons, then it will automatically turn off the
# bridge (equivalent to setting bridgeEnabled to False) and also
# switch presentMainWindowFromServer to False and then continue to
# render client output into the main window without use of the
# bridge if client.serverCrashFallback is enabled. The user will then
# see graphics output change from the raytraced output to the original
# game content. Once in this state RTX cannot be enabled again until
# the game is relaunched. If client.serverCrashFallback is disabled
# then the game will crash in this case.
# Making these values larger will not have any noticeable impact
# unless there is one of the timeout situations described above, and
# the client or server process will appear hung and unresponsive for
# a longer amount of time.
# Making these values too small can lead to timeout issues during
# startup or regular operation. It is not recommended to change these
# values from their defaults of 1000 ms timeout and 300 retries, which
# means a 5 minute total timeout until remedial action is taken.
# The startup timeout value is only used during the initial handshake
# performed by the bridge client and server components to initialize
# the bridge and synchronize both process loops. The startup is
# typically quick, therefore we shorten the total timeout to 30 seconds
# total before aborting and exiting.
#
# Supported values:
# commandTimeout: Any integer from 1 to 4,294,967,295
# commandRetries: Any integer from 0 to 4,294,967,295

# commandTimeout = 1000
# startupTimeout = 100
# commandRetries = 300


# The acknowledgement timeout is enforced at runtime on acknowledgement
# commands like Bridge_Ack and Bridge_Continue to avoid hitting the long
# waits when an unexpected command is picked up from the queue.
# The default value is 10ms because typically we only need to wait a
# short amount of time until we can try again. Making this value larger
# will introduce noticable delays and slow down rendering.
#
# Supported values: Any integer from 1 to 4,294,967,295

# ackTimeout = 10


# When set to true this setting ignores the commandRetries value that
# is defined in the settings and uses the maximum value instead. This
# is used internally to ensure that timeouts do not occur during
# normal operation when the game window becomes inactive due to being
# minimized or because the user switched to another process, which may
# temporarily suspend rendering activity in the game window.
# Note that this setting may be changed dynamically at runtime to
# respond to the current application state, therefore changing its
# default value may not have any noticeable effect overall.
#
# Supported values: True, False

# infiniteRetries = False


# Sets the log level used for writing log output to the bridge client
# and server log files. Both the client and server share the same log
# level, even though they use separate log files.
# The client log file is located in the same directory as the bridge
# d3d9.dll. The log file is called d3d9.log.
# The server log file is located in the .trex subdirectory on the same
# level as the client dll, and is called server.log.
# The log files are overwritten at each launch, and currently have no
# maximum size or rollover capabilities.
# Log levels are pretty self-explanatory with Trace being the most
# verbose level and None turning logging off entirely. Note that for
# debug builds the log level is automatically initialized with Debug
# level by default instead of Info, which is the default for release
# builds.
#
# Supported values: Trace, Debug, Info, Warn, Error, and None

# logLevel = Info


# The receiving (x64) end of the bridge will not hear the WinProc input
# messages that are sent to the game/app window. Without receiving
# those messages, DXVK settings + GUI/overlay is not interactable. A
# simple circular buffer is used to track user input state in order to
# send it over the bridge for dxvk developer/user overlay manipulation.
# This option sets the max size of the circ buffer, which stores 2B
# elements. 100 is probably overkill, but it's a fairly small cost. If
# user input to the DXVK GUI/overlay is getting noticeably dropped,
# this value should probably be increased.

# Supported values: [1, 65535]

# keyStateCircBufMaxSize = 100


# Under Normal Operation the commandTimeout, startupTimeout, and 
# commandRetries values determine the timeout durections and retry
# counts for bridge client server IPC (interprocess communication).
# If disableTimeoutsWhenDebugging is True, the aformentioned values
# are overwritten to the maximim value for the timeouts and to 1
# for commandRetries when the component is launched with a debugger
# or a debugger attaches to it. This has the practical effect of 
# disabling the timeouts when the bridge components are being debugged.

# Supported values: True, False

# disableTimeoutsWhenDebugging = True


# Functions similar to the disableTimeoutsWhenDebugging setting above,
# except that no debugger needs to be attached for timeouts to get
# disabled. This is used internally for when the game window becomes
# inactive because the user switches to another process, which may
# suspend rendering activity in the game window which could trigger
# bridge timeouts.
# Note that this setting may be changed dynamically at runtime based
# on application state, therefore changing the default in the settings
# does not have much of an effect overall.

# disableTimeouts = False


# Rather than copying an entire index/vertex/etc. buffer on every
# buffer-type Unlock(), the bridge instead directly stores all buffer
# data into a shared memory "heap" that both Client and Server are able
# to access, providing a significant performance boost. See sharedHeapPolicy
# below for selecting which types are best suited for a given game.

# Supported values: True, False

# useSharedHeap = False


# Shared heap usage policy. A comma-separated set of rules for enabling
# shared heap for various graphics objects. By default enabled for only
# textures and static buffers. Dynamic buffers are changed much too often
# with DISCARD flags, and cause fragmentation issues.
#
# Supported values: Textures - use shared heap for textures.
#                   DynamicBuffers - use shared heap for dynamic buffers.
#                   StaticBuffers - use shared heap for static buffers.

# sharedHeapPolicy = Textures, StaticBuffers


# Size of individual segments of the "shared heap".
# If above useSharedHeap == True.

# Supported values: Any valid binary ("0bXXXX"), hex ("0xXXXX"), decimal ("XXXX"),
#                   or kb/MB/GB ("2GB") values. Should not exceed 1GB.

# sharedHeapDefaultSegmentSize = 256MB


# Size of individual "chunks" as they are carved out in the "shared heap".
# Fundamental SharedHeap allocation unit size; e.g. if game requests 100B,
# game gets 4kB.
# If above useSharedHeap == True.

# Supported values: Any valid binary ("0bXXXX"), hex ("0xXXXX"), decimal ("XXXX"),
#                   or kb/MB/GB ("2GB") values.

# sharedHeapChunkSize = 4kB


# The number of seconds to wait for an avaliable chunk to free up in the shared
# heap

# Supported values: Any integer from 0 to 4,294,967,295

# sharedHeapFreeChunkWaitTimeout = 10


# Thread-safety policy
# To have an effect, bridge must be built with thread-safety support enabled.
#
# Supported values: 0 - client's choice, 1 - force thread-safe,
#                   2 - force non-thread-safe

# threadSafetyPolicy = 0


# Whether or not to allocate and use shadow memory for dynamic buffers.
# Aggressive dynamic buffers use with discarding may put a significant
# pressure on the shared heap and may also result in unnecessary fragmentation.
# When this option is enabled a shadow memory will be allocated for each
# dynamic buffer and its data will be transferred on the data queue. When enabled
# this option supersedes shared heap usage policy for dynamic buffers.
# The total size of allocated shadow memory is reported in the log and may be used
# for evaluating the overall RAM cost in the client's x86 process heap.
#
# Supported values: True, False

# useShadowMemoryForDynamicBuffers = False