GPU and Feature Tables

Overview

There are a set of configuration files in the Second Life install folder that control the default settings and overrides for various graphics chips on different platforms:

• gpu_table.txt - assigns a "class" to a graphics chip
• feature_table(_linux/_mac/_xp).txt - defines specific features to be enabled or disabled by default based on a variety of conditions

GPU Table

The GPU table is uniform for all platforms and contains a list of regular expressions that match GPU names reported by graphics drivers to a specific chip or category of chips. Each entry is of the format:

<recognizer name> <regular expression> <class> <supported>

These fields are defined as:

• recognizer name - a human readable identifier for that chip
• regular expression - a regular expression used to match driver reported names
• class - a simplistic categorization of the chip's capabilities (see below)
• supported - 0 or 1, indicating unsupported or supported. If a name reported by the driver cannot be matched to a regular expression in the table, it is assumed to be unsupported

GPU Class

There are currently four classes of GPU:

• Class 0 - low power or obsolete hardware, defaults to "low" detail.
• Class 1 - Low power or "economy" hardware, defaults to "mid" detail.
• Class 2 - Mid-range or "mainstream" hardware, defaults to "high" detail.
• Class 3 - High-end or "enthusiast" hardware, default to "high" detail.

Issues

Since it is impractical to test every graphics chip in the wild today, many chips will be improperly categorized, and some will be missing outright. This is particularly problematic with new chips. Often, when upgrading your graphics hardware to the latest and greatest, the gpu_table will not contain an entry for your new (and very capable) hardware, which will cause your graphics settings to default to "low." It's also important to note that the order of declaration of regular expressions matters. Strings are checked top to bottom in the table, and checking stops as soon as the first match is found. Therefore, it is important to put more general regular expressions lower in the list than more specific ones.

Testing Changes

In the [viewer source] there is a script:

scripts/gpu_table_tester

given a set of input strings, it prints out how those are recognized by a given gpu table. Run the script with a --help argument for usage information. A set of gpu identifiers seen in the wild and the corresponding output from the tester are also checked into the source tree at:

indra/newview/tests/gpus_seen.txt
indra/newview/tests/gpu_results.txt

before checking in a change to the gpu table, use that script to generate new output and compare it to the previous results so that you can see that you had the intended effect. Check in the updated results with the table changes.

Feature Table

The feature table contains a list of settings to apply on various conditions. At startup, if the client is being run for the first time or the "version" number at the top of the feature table is greater than the version number of the previous session, the viewer will run through this list and apply the specified settings based on the configuration of the machine. The table is divided into "list" sections that each contain a set of settings (as defined in "settings.xml") and their suggested values, as well as whether or not the "feature" denoted by that setting is available. This controls whether or not certain preferences will be disabled in the UI and allows for fine control over different settings based on a variety of factors, such as installed graphics chip, GL version, amount of available memory, etc.

Platform Specific Tables

• featuretable.txt -- used for Windows Vista/Server 2008 and later
• featuretable_xp.txt -- used for Windows XP and Server 2003
• featuretable_linux.txt -- used for Linux
• featuretable_mac.txt -- used for OSX

GPU Based Lists

To create a list specific to a particular GPU, use the "recognizer" name from the gpu_table and replace spaces with underscores. For example, when occlusion culling was causing many crashes or performance problems on a particular intel chip, the following section was added to disable occlusion culling for all Intel 965 chips:

list Intel_965
UseOcclusion 0 0


Live Updates

In an emergency such as the introduction of a bug that causes a particular feature to crash at an alarmingly high rate, the feature tables and gpu tables may be updated live by uploading them to a bucket on S3 which is checked by the viewer at every startup. If a featuretable or gpu table exists in this bucket for the specific build of the viewer, it will be retrieved and used on the next session instead of the currently installed tables. The currently used bucket is "viewer-settings.secondlife.com" and the method for specifying the build to apply the table to is to suffix the full build version number prior to the ".txt" on the filename. Don't forget to set the ACL of the new file so that "Everyone" can read it.

• For example: http://viewer-settings.secondlife.com.s3.amazonaws.com/featuretable.2.2.0.212097.txt

This technique can also be used during a beta to enable verbose debugging for a particular GPU without the need for a new build.