Graphics card profiles: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
Line 20: Line 20:
   }}</ref>
   }}</ref>


Furthermore, suggesting that it could be a good idea to make sure the configuration has at least 20fps at KSFO.
Furthermore, people agreed that it could be a good idea to make sure the configuration has at least 30fps at the default airport.
 
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.<ref>{{cite web
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.<ref>{{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=275411#p275411
   | url    = http://forum.flightgear.org/viewtopic.php?p=275411#p275411

Revision as of 17:10, 24 February 2016

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

Motivation

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

Background

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.

Idea

This approach is largely inspired by the way FlightGear already supports a variety of different joysticks and other I/O hardware using XML-configurable hardware profiles.

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). [1]

Furthermore, people agreed that it could be a good idea to make sure the configuration has at least 30fps at the default airport.

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.[2]

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. [3]

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 [4] :

Resource Tracking for FlightGear Sigar-support.png

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 About dialog 2.10.png

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. [5]

  1. erik (Feb 7th, 2016). Re: Review of FG on reddit: xpost.
  2. erik (Feb 8th, 2016). Re: Review of FG on reddit: xpost.
  3. Thorsten (Feb 7th, 2016). Re: Review of FG on reddit: xpost.
  4. Hooray (Feb 7th, 2016). Re: Review of FG on reddit: xpost.
  5. Hooray (Feb 8th, 2016). Re: Review of FG on reddit: xpost.

Approach

It's basically a form of feature-scaling: Feature Scaling

We could expose most of the GL* info at the property tree level, and then use Nasal/propertylist rules (and/or SGConditions) 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.[1]

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. [2]

We could provide a --disable-gpu-profiles parameter to resort to the old/standard 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 [3]


  1. Hooray (Feb 7th, 2016). Re: Review of FG on reddit: xpost.
  2. Hooray (Feb 7th, 2016). Re: Review of FG on reddit: xpost.
  3. Hooray (Feb 7th, 2016). Re: Review of FG on reddit: xpost.

Implementation

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[1]


  1. Hooray (Feb 8th, 2016). Re: Review of FG on reddit: xpost.