Graphics card profiles: Difference between revisions
| Line 112: | Line 112: | ||
{{FGCquote | {{FGCquote | ||
|1= 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. | |1= 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 | For instance, see $FG_SRC/Main/fg_init.cxx +466 fgInitConfig(): | ||
<syntaxhighlight lang="cpp"> | |||
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"); | |||
</syntaxhighlight> | |||
This is one of the places, where we could also run another fgLoadPRops() call to load rendering settings that are overlaid onto /sim/rendering | This is one of the places, where we could also run another fgLoadPRops() call to load rendering settings that are overlaid onto /sim/rendering | ||
Revision as of 16:44, 24 February 2016
| This article is a stub. You can help the wiki by expanding it. |
Idea
|
The only thing I want to do is 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 default 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). |
|
|
|
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. |
|
|
|
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. |
|
|
|
You 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  |
|
Approach
|
|
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:
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. |
|
|
|
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. |
|
|
|
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 |
|
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 |
|