Graphics card profiles

This article is a stub. You can help the wiki by expanding it.

Idea

This idea dates back to early 2016 when a few FlightGear contributors were discussing a reddit review of FlightGear which highlighted that FlightGear's default graphics settings didn't seem to fit/match the graphics hardware available.

FlightGear core deveoper Erik Hofman came up with the idea to preselect more appropriate default settings based on parsing various GL_* strings (in particular GL_VENDOR), i.e. detect the video card and based on the GL renderer name turn on ALS (or not), turn on water shader (or not), turn on the 3d city shader (or not), etc.

The defaults would not be touched but based on the detected video card certain options would get enabled, making the first impression much more pleasant (for first time users).

Furthermore, suggesting that it could be a good idea to make sure the configuration has at least 20fps at KSFO. Also it would be a one time configuration for after a (re)install. The settings would be written to a local configuration afterwards so users could still tweak for their own liking.

Other contributors, like Thorsten mentioned, that it does not seem to be a technical problem - to query a string from the property tree is easy, to write a routine which sets other properties based on what the string says is equally easy. The problem is the meat of it - someone has to know what settings are likely to run on what graphics cards. And someone has to write the routine that does it. Then it's done.

We can do that by settings /sim/rendering/* as required, i.e. loading pre-configured profiles from $FG_ROOT CPU/RAM and VRAM info is not currently available, but we have patches providing this sort of info  :

Resource Tracking for FlightGear

For example, $FG_ROOT/gui/dialogs/about.xml and rendering.xml are already accessing some of the GL* data via properties, e.g. to display the Intel warning, but also the GPU vendor info: About dialog

Thus, we would ideally introduce 3-4 "vendor"-specific folders and then introduce a PropertyList XML file where the RENDERER string is used to select a certain default configuration. For testing purposes, we could promote this features on the forum/website/IRC and facebook to get people involved with testing, and to provide feedback - so that we know what settings work well enough, using Nasal's http APIs, such feedback could even be gathered online.

Approach

Note  In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives). While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible.

that's basically a form of feature-scaling: Feature Scaling Like you say, we could expose most of the GL* info at the property tree level, and then use Nasal/propertylist rules to dynamically toggle features on/off during startup, i.e. sort of a better customiable initialization sequence. The easiest way to implement something like this would be supporting "data overlays", i.e. in the form of fgfsrc/preferences.xml files that are stored in $FG_ROOT/Profiles and automatically overlaid over default startup options once a certain GL vendor/make and GPU model are detected, e.g. by having: $FG_ROOT/GraphicsProfiles/NVIDIA $FG_ROOT/GraphicsProfiles/AMD-ATI $FG_ROOT/GraphicsProfiles/INTEL $FG_ROOT/Graphics Profiles/MATROX $FG_ROOT/GraphicsProfiles/Other Each vendor-specific sub-folder could then contain graphics related xml overlays that will be loaded on top of the default startup options (i.e. those not customized/overriden by the user) - what that means is that the current hard-coded default settings in fg_init.cxx would need to be dynamically loaded during startup using the APIs from props_io.cxx. The corresponding startup profiles could be either conventional PropertyList XML files, or support embedded Nasal/property-rule blocks to provide support for regex-matching etc. — Hooray (Feb 7th, 2016). Re: Review of FG on reddit: xpost. (powered by Instant-Cquotes)

This is something where it would make sense to provide a benchmark and test various combination of settings on different systems and gather all results in a central database to determine a safe subset of settings that should work for most AMD/ATI, NVIDIA and Intel boards - note that the CrashRpt tool is already gathering feedback on crashes and sending that to a webserver, where it is stored in a database. — Hooray (Feb 7th, 2016). Re: Review of FG on reddit: xpost. (powered by Instant-Cquotes)

We could provide a --disable-gpu-profiles to resort to the old behavior, or require people to explicitly enable the new system via something like --enable-gpu-profiles, i.e. trying to pick an appropriate set of standard settings The more difficult thing is fixing up subsystems that are not currently able to be reset/restarted with restarting FG as a whole Note that the rendering settings dialog will already detect the INTEL substring and show a warning if appropriate — Hooray (Feb 7th, 2016). Re: Review of FG on reddit: xpost. (powered by Instant-Cquotes)

Implementation

like you said already, this could work pretty much like the joystick support - i.e. we would maintain PropertyList XML files in $FG_ROOT/GraphicsProfiles/VENDOR, and then use the GL_* strings to load a matching default profile, with CLI arguments being processed afterwards, i.e. to take precedence, so that defaults can be overridden. For instance, see $FG_SRC/Main/fg_init.cxx +466 fgInitConfig(): bool loadDefaults = options->shouldLoadDefaultConfig(); if (loadDefaults) { // Read global preferences from $FG_ROOT/preferences.xml SG_LOG(SG_INPUT, SG_INFO, "Reading global preferences"); fgLoadProps("preferences.xml", globals->get_props()); SG_LOG(SG_INPUT, SG_INFO, "Finished Reading global preferences"); This is one of the places, where we could also run another fgLoadPRops() call to load rendering settings that are overlaid onto /sim/rendering Technically, we are already using this approach to suport translations, which are also read/overlaid into the tree — Hooray (Feb 8th, 2016). Re: Review of FG on reddit: xpost. (powered by Instant-Cquotes)