Board index FlightGear Support Graphics

Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Graphics issues like: bad framerates, weird colors, OpenGL errors etc. Bad graphics ar usually the result of bad graphics cards or drivers.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?
- does the problem occur with any aircraft, at any airport?
- is there any output printed to the console (black window)?
- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).
- please upload a screenshot of the problem.

If you experience FlightGear crashes, please report a bug using the issue tracker (can be also used for feature requests).
To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article. If you are seeing corrupted/broken textures, please see this article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

Re: Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Postby GinGin » Thu Nov 21, 2019 10:08 am

Perfect :)
I will watch that .

I was saying not massively significant compared to what v12 would expect from a multi threading stuff .

Anyway , that is a very interesting work Richard .
How hard is it behind the lines ?
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Postby icecode » Thu Nov 21, 2019 10:11 am

Richard wrote in Wed Nov 20, 2019 8:14 pm:When I'm using my experimental multi-threaded rendering there is a small increase in performance which is almost equivalent to the 3.7ms of "the rest" - that usually works out to about an extra 10fps (on my system, with the F-15)


In my particular case I've noticed that the simulation usually takes around 7 to 8 ms on moderately complex aircrafts. That's a bit more than the performance cost of shadow mapping under the Compositor. It would be really interesting if we could get the simulation on a separate thread in FG. It's not a huge improvement, but it definitely improves framerate and allows other systems to use the spare ms. Are there any important issues preventing this from reaching upstream Richard?
icecode
 
Posts: 709
Joined: Thu Aug 12, 2010 1:17 pm
Location: Spain
Version: next
OS: Fedora

Re: Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Postby V12 » Thu Nov 21, 2019 1:29 pm

Analyze of P3D v4.3 Academic :
Machine :

AMD R7 3700X, 8 cores, 16 threads
32 GB RAM
3600 MHz RAM
M.2 SATA drive
nVidia 1060 GTX 3 GB

1. Only one core forced by set affinity to CPU #0 :
Image
CPU #0 full load, overal CPU load 9%, CPU automaticaly boosted to 4.22 GHz (nominal 3.6 GHz), low image quality, totaly blured textures, autogen displayed too late or missing, lags, visualy low FPS (I'm not familiar with this software, I don't know how display fps), time between click on OK before flight and moment, when P3D displays cockpit of the plane - cca 1 minute, view switching take more than 5 seconds to full display model, aircraft steering delayed, jerky

2. All cores, V-SYNC ON
Image
CPU #0 average load almost 90%, overal load 60%, fps hit 60 Hz refresh frequency of my monitor, this is reason, why CPU #0 is not on 100%, perfect image quality, time to load 15 seconds, not visible stuttering, lagging, views switching instantly, aircraft steering precise

3. All cores, V-SYNC OFF - maximal possible power from CPU
Image
CPU #0 full load, overal CPU load 70%, perfect image quality, time to load 15 seconds perfect image quality, not visible stuttering, lagging, views switching instantly, aircraft steering precise
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Postby Richard » Thu Nov 21, 2019 2:35 pm

The +10FPS is based on the tests that I performed earlier; obviously the more time spent rendering the less improvement can be had from multi-threading the simulation.

The UFO generally takes 1.7ms simulation (non rendering time).

Testing at Paris with the UFO gives a rendering time of 36.08ms which is equal to 27.7 fps (just considering the frame drawing, overall this number is 26.5); therefore the maximum improvement (for the UFO) with 1.7ms of simulation time would be to 27.7fps - which isn't really that significant and in this case is less than 5% of CPU spent on simulation tasks.

If I'd have been in the F-15 over Paris the maximum rate would still be 27.7fps, but it is likely that the single threaded rendering would be 23.8 FPS (rather than 26.5)

Image
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Postby Richard » Thu Nov 21, 2019 2:48 pm

Icecode GL wrote in Thu Nov 21, 2019 10:11 am:Are there any important issues preventing this from reaching upstream Richard?


Yes - the second camera position sometimes is moved compared to the first camera as the simulation updates it. The way that the multithreading works is to start the simulation frame after the rendering has started drawing. I suspect that this probably isn't that hard to fix.

The stability of the multi-threaded rendering is good; but it is still very much experimental.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Postby Richard » Thu Nov 21, 2019 3:34 pm

V12 wrote in Thu Nov 21, 2019 1:29 pm:Analyze of P3D v4.3 Academic :
Machine :

AMD R7 3700X, 8 cores, 16 threads
32 GB RAM
3600 MHz RAM
M.2 SATA drive
nVidia 1060 GTX 3 GB


Thanks for taking the time to do some analysis - and it is somewhat interesting - but it doesn't really help us to be able to determine what they are doing to achieve the CPU usage, it's interesting that when locked to a single core the quality suffers.

I think it is Shift-Z to show debug/frame rate info.

However none of this really helps us in getting better performance for FG.

I suspect that the truth is that the current OpenSceneGraph version of FlightGear will never see any significant frame rate benefit from using CPUs with lots of cores.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Postby V12 » Thu Nov 21, 2019 4:06 pm

Yes, I know that my analyze is pointless for FG, but it is clearly evidence that spread non rendering tasks on many CPU cores has visible benefits.
There is big difference between FSX / P3D and FG rendering core - in FSX textures are rasterized from vector layers (landclasses, roads, railways, rivers, streams, lakes, snow chunks, street light maps, lamps lightmaps etc), and applied on the global mesh. This manner allows smooth texture blending, fractalize landclass boundaries etc, what is not allowed in classic method - take textures, blend it with other textures based on some rules with shaders in GPU and apply them on polygon. You don't need solve elevation for roads or railways geometry. MS method has minimal one large advantage - texture preprocess should be spreaded on as many CPUs as available. Then rendering process on GPU is very simple (GPU power 13 years ago was not enough for massive shader operations).
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Postby Richard » Thu Nov 21, 2019 5:10 pm

V12 wrote in Thu Nov 21, 2019 4:06 pm:Yes, I know that my analyze is pointless for FG, but it is clearly evidence that spread non rendering tasks on many CPU cores has visible benefits.
There is big difference between FSX / P3D and FG rendering core - in FSX textures are rasterized from vector layers (landclasses, roads, railways, rivers, streams, lakes, snow chunks, street light maps, lamps lightmaps etc), and .


Your P3D analysis isn't pointless it has interest for me whereas FSX is irrelevant because it isn't under active development and obsolete technically.

There is a possibility that FG may have a similar method of rasterizing the shapefile (vector) data at run time - and that would benefit from multiple cores - as it is in the paged database loader in OSG - and I've actually managed to get around 75% usage on FG with 28 scenery loading threads; however this no effect on the main frame rate.

Removing frame pauses from the core is something that I've been working on a lot - which is why we have the DDS texture cache and the background Nasal garbage collector; however some frame pauses are caused by specific aircraft models and these aren't something we can fix in the core. At the moment I'm not aware of any more code that can be improved; there are still pauses but I haven't identified what these are or if they can be fixed.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Postby Hooray » Sun Nov 24, 2019 3:27 pm

if you haven't already, I would report those via the issue tracker and/or via the devel list or to Icecode directly, given Thorsten's degree of involvement in the shuttle, and his background in shaders and effects, I am not surprised seeing that the compositor may not yet be quite ready for the shuttle ;-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Postby wkitty42 » Sun Nov 24, 2019 6:45 pm

there's a few bugs in the way but once these next few patches that are in the pipeline are applied, more bugs will be squashed... we're just waiting on the patches to be reviewed, IIRC... icecode has the info, though...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Threadripper 1920 (12/24 threads)+Vega56 = 10fps in W10?

Postby Hooray » Sun Nov 24, 2019 7:41 pm

Richard wrote:Removing frame pauses from the core is something that I've been working on a lot - which is why we have the DDS texture cache and the background Nasal garbage collector; however some frame pauses are caused by specific aircraft models and these aren't something we can fix in the core. At the moment I'm not aware of any more code that can be improved; there are still pauses but I haven't identified what these are or if they can be fixed.


A number of core devs have repeatedly posted observations that fgfs vs. fgviewer performs not as well as expected, and that fgviewer does not perform as well as osgviewer.

Personally, I have had good success by simply excluding the usual suspects from the equation, i.e. using build time/runtime switches to disable certain feature and benchmark/profile fgfs with and without those features (think Nasal vs. Canvas shown/hidden).

That is one of the reasons why I have shared patches to optionally disable entirely, while it's obviously not very useful for end-users, it does help to exclude Nasal from the list of potential culprits, also as James and Stuart repeatedly said, it does help to add more and more draw masks, including boolean properties to enable/disable those.

For instance, these can be trivially added per canvas, but also per canvas placement - that way, it is easy to determine the overhead of individual canvas textures, but also the in-scene placement.

Also, there are patches on the forum and the wiki, that show how to add more/better runtime information to the property tree, e.g. stuff like CPU/RAM utilization, but even VRAM use, as well as paging info:

http://wiki.flightgear.org/Resource_Tra ... ar#Gallery
Image
Image


As for Canvas things, it would also be possible to add osg stats per canvas, so that these can be optionally toggled on/off, just for canvas cameras - e.g. to see what your MFD is doing behind the scenes in terms of Nasal, property I/O and updating/rendering

Speaking in general, it would seem like a good idea to use a different SGEventMgr instance for different timers, i.e. aircraft stuff vs. scenery stuff vs. gui stuff vs. addons, and then overload the _settimer/maketimer APIs respectively - this could be the first step towards having separate Nasal contexts for different types of scripts

I don't think, this is primarily a matter of fixing existing issues, but of making additional info available at runtime, i.e. in the property tree, so that this can be used to look behind the scenes - analogous to how the system monitor can be used to visualize SGSubsystem internals, or to how the osg stats can help track rendering stuff.

Likewise, as long as we have these data points available in the form of live properties, we can actually use those at runtime to come up with all sorts of interested benchmarks to profile different combinations of fgfs features (code paths), and eventually use those to "feature scale" fgfs at runtime, using the existing PID machinery we have already, as per James original idea: http://wiki.flightgear.org/Feature_Scaling
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Previous

Return to Graphics

Who is online

Users browsing this forum: No registered users and 1 guest