Some features of Wine Staging are experimental and affect so many parts of Wine that they cannot be configured through winecfg or a registry key. In these cases we decided to add an environment variable that allows you to enable/disable the feature. The following list contains a description of the supported environment variables and what they are supposed to do.
The STAGING_WRITECOPY environment variable can be used to simulate the memory management system of Windows more precisely. Windows loads dlls only a single time into the memory when multiple applications want to use the same dll. This should lower the memory usage and Windows will only create a copy of them if an application tries to modify them (Copy-on-Write). On Wine it will have no effect on the memory usage, but an application can check if a dll was already modified in the current process and some programs (for example Voobly) fail if this information is incorrect.
You can enable the feature simply by starting a program using
STAGING_WRITECOPY=1 /opt/wine-staging/bin/wine game.exe
The feature is currently not enabled by default since it revealed further bugs in Wine. Please help us by testing programs with this feature enabled and report bugs in our Bugtracker so that we can enable this feature by default in future versions.
Wine Staging can optimize some wineserver calls by using shared memory. While this only brings a small performance improvement for most programs, it can result in a big improvement for applications which use specific API functions in an excessive way. This feature can be enabled through STAGING_SHARED_MEMORY and is only available for Linux with kernel >= 3.17 at the moment. We are going to enable it for more platforms in future versions.
In order to use this feature make sure that the wineserver was started using this environment variable (i.e. no other programs are currently running in the WINEPREFIX)
STAGING_SHARED_MEMORY=1 /opt/wine-staging/bin/wine game.exe
The Realtime Priority patchset allows applications running in Wine to use higher priority levels on Linux than they are usually allowed to use.
You can change the priority level on the wineserver by setting the STAGING_RT_PRIORITY_SERVER environment variable, which has a similar effect like using shared memory. The wineserver is usually idling and waiting for new requests, so setting a higher priority causes the system to schedule the wineserver faster and double the throughput in wineserver benchmarks.
It is also possible to change the priority of all programs running in Wine by setting STAGING_RT_PRIORITY_BASE though this will usually not result in big performance improvements. The linux kernel will reduce the priority again if an application does not idle often enough and most games therefore may even run slower this way. We recommend changing the priority only for the wineserver since this gives you a small performance improvement without the risk of slowing down your application, but feel free to try it yourself.
Before you can make use of the realtime priority levels, you need to give the wineserver the permission to use them.
The easiest and simplest way is to set file capabilities on the wineserver:
sudo setcap cap_sys_nice+ep /opt/wine-staging/bin/wineserver
This should be enough on most systems, but will be reset on a wine staging update.
Alternatively, you can give your user the permission to use the realtime priorities in all programs. Some distributions already provide an audio group that grants you these permissions. If this is not the case, you can add the following entry to /etc/security/lmits.conf:
@userOrGroup - rtprio 90 @userOrGroup - nice -10
Now logout and back in.
Use RT priorities
In case you want to change the priority of the wineserver, make sure that the server was not started yet. Now start your application using:
STAGING_RT_PRIORITY_SERVER=90 STAGING_RT_PRIORITY_BASE=90 /opt/wine-staging/bin/wine test.exe
The priority must be between 1 (lowest) and 99 (highest). You do not need to use both of them, simply skip one if you don't want to enable it or set it to 0. Note that you probably should not use 99, as the kernel has some housekeeping threads running at this priority. More information can also be found in the patch submission request where this feature was added.