Hackathon Proposal:Feature Scaling: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(placeholder based on hackathon ideas discussed on the devel list: https://sourceforge.net/p/flightgear/mailman/message/37129569/)
 
mNo edit summary
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{WIP}}


{{Hackathon Proposal
{{Hackathon Proposal
Line 5: Line 4:
|image = OSG-OnScreen-Stats.png
|image = OSG-OnScreen-Stats.png
|imginfo = screen shot showing the OSG on-screen stats
|imginfo = screen shot showing the OSG on-screen stats
|sponsor= <!-- {{Usr|Stuart}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37129171/ </ref>-->
|sponsor= {{Usr|Stuart}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37129171/ </ref>
|supporters= please add yourself if you are interested in working on this
|supporters= please add yourself if you are interested in working on this
|summary =  a test mode, which flies a 30 second replay tape with the C172 around Hawaii, measures the FPS and repeats for each graphical config: that would be reasonably simple to code up, and give something approximating a sane value (modulo all the zillion ways it can screw up, but…) <ref>https://sourceforge.net/p/flightgear/mailman/message/37129569/</ref>
|summary =  a test mode, which flies a 30 second replay tape with the C172 around Hawaii, measures the FPS and repeats for each graphical config: that would be reasonably simple to code up, and give something approximating a sane value (modulo all the zillion ways it can screw up, but…) <ref>https://sourceforge.net/p/flightgear/mailman/message/37129569/</ref>
|background= There is a performance problem in OSG with too many LOD nodes deep down in the tree, but that’s the usual ‘too many nodes == small batch sizes ==  too many draw calls == sucky performance’ problem.
|background= There is a performance problem in OSG with too many LOD nodes deep down in the tree, but that’s the usual '''too many nodes == small batch sizes ==  too many draw calls == sucky performance''' problem.


But there’s no problem with LOD nodes per-se, they just need to be high up in the tree, switching large amounts of stuff, eg a complete tile, not one window on the front door of a house :) And OSG LOD nodes can use distance or screen-space pixel metrics, and they update per frame, so you could absolutely increase the visibility, but reduce the detail levels, with increasing altitude; turning off trees, OSM buildings, and then /all/ objects.  <ref>https://sourceforge.net/p/flightgear/mailman/message/37129429/</ref>
But there’s no problem with LOD nodes per-se, they just need to be high up in the tree, switching large amounts of stuff, eg a complete tile, not one window on the front door of a house :) And OSG LOD nodes can use distance or screen-space pixel metrics, and they update per frame, so you could absolutely increase the visibility, but reduce the detail levels, with increasing altitude; turning off trees, OSM buildings, and then /all/ objects.  <ref>https://sourceforge.net/p/flightgear/mailman/message/37129429/</ref>


|details=
|details=One issue is if people are connecting FG to a 2k-4k monitor with a marginal GPU. Such a monitor might be fine for text or 2d digital art, but run into problems in 3d. A way to avoid this would be to force 1080p by default with a message that theri GPU may struggle with the native LCD resolution - and an explanation flightgear can use GPU power to create interesting detail and content or render more of the same (boring) pixels.
 
Another issue is turning up settings like tree density for a GPU that's in a system with a a slower processor or maybe not much RAM. NVIDIA 10 series and newer use drastically less power - so they can be installed on much older systems sometimes without a power connector. Laptops use desktop GPUs from the 10 series onward, so they may come with less RAM. The LoDs also need to be definitely default, as a high rough LoD can increase RAM usage. RAM/VRAM usage by trees (and instanced shader buildings) can be reduced a hugely by using UBOs if UBO support is added in future - the current method stores copies of the full instancing data as vertex attributes for each vertex.
 
Currently the RAM and CPU stats are not available in the GPU profile system <ref>https://sourceforge.net/p/flightgear/mailman/message/37129612/</ref>
|skills= [[Property tree]], [[PropertyList XML File]], [[Nasal]], [[Instant Replay]], [[Fgtape]], [[Logging properties]]
|skills= [[Property tree]], [[PropertyList XML File]], [[Nasal]], [[Instant Replay]], [[Fgtape]], [[Logging properties]]
|opportunities=</p>
|opportunities=</p>
Line 20: Line 23:
* [[Feature Scaling]]
* [[Feature Scaling]]
* [[Graphics card profiles]]
* [[Graphics card profiles]]
|notes =
|notes = You know this is already mostly implemented right?
https://forum.flightgear.org/viewtopic.php?f=37&t=29122
 
The only drawback is that it is currently aimed at a specific card from
a specific vendor. This might need to be altered to get one
configuration file to work for a complete range of video cards.
 
There is even an option in the debug menu to dump all required settings
from the current configuration to an XML file which can be directly
copied to FGData. But these settings might not be up to date anymore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129556/</ref>
 
}}
}}

Latest revision as of 19:57, 21 September 2021


Title: Automatic/abstracted rendering settings (Feature Scaling)

screen shot showing the OSG on-screen stats
Potential mentors: Stuart [1]
Intro: (short intro)
Interested Parties: please add yourself if you are interested in working on this
Status: n/a
Summary: a test mode, which flies a 30 second replay tape with the C172 around Hawaii, measures the FPS and repeats for each graphical config: that would be reasonably simple to code up, and give something approximating a sane value (modulo all the zillion ways it can screw up, but…) [2]
Background: There is a performance problem in OSG with too many LOD nodes deep down in the tree, but that’s the usual too many nodes == small batch sizes == too many draw calls == sucky performance problem.

But there’s no problem with LOD nodes per-se, they just need to be high up in the tree, switching large amounts of stuff, eg a complete tile, not one window on the front door of a house :) And OSG LOD nodes can use distance or screen-space pixel metrics, and they update per frame, so you could absolutely increase the visibility, but reduce the detail levels, with increasing altitude; turning off trees, OSM buildings, and then /all/ objects. [3]

Details: One issue is if people are connecting FG to a 2k-4k monitor with a marginal GPU. Such a monitor might be fine for text or 2d digital art, but run into problems in 3d. A way to avoid this would be to force 1080p by default with a message that theri GPU may struggle with the native LCD resolution - and an explanation flightgear can use GPU power to create interesting detail and content or render more of the same (boring) pixels.

Another issue is turning up settings like tree density for a GPU that's in a system with a a slower processor or maybe not much RAM. NVIDIA 10 series and newer use drastically less power - so they can be installed on much older systems sometimes without a power connector. Laptops use desktop GPUs from the 10 series onward, so they may come with less RAM. The LoDs also need to be definitely default, as a high rough LoD can increase RAM usage. RAM/VRAM usage by trees (and instanced shader buildings) can be reduced a hugely by using UBOs if UBO support is added in future - the current method stores copies of the full instancing data as vertex attributes for each vertex.

Currently the RAM and CPU stats are not available in the GPU profile system [4]

Ideas:
Required skills: Property tree, PropertyList XML File, Nasal, Instant Replay, Fgtape, Logging properties
Learning Opportunities:

Notes: You know this is already mostly implemented right?

https://forum.flightgear.org/viewtopic.php?f=37&t=29122

The only drawback is that it is currently aimed at a specific card from a specific vendor. This might need to be altered to get one configuration file to work for a complete range of video cards.

There is even an option in the debug menu to dump all required settings from the current configuration to an XML file which can be directly copied to FGData. But these settings might not be up to date anymore.[5]

References