Board index FlightGear Release candidates

FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Release candidate testers are encouraged to post their feedback here. Please read the introduction topic for details.
Forum rules
Please read the introduction topic for details.

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby rogerx » Thu Oct 15, 2015 3:40 pm

Thorsten: "Well, that's your problem on the horizon."

Shrugs. Sounds like somebody has a problem here communicating.

I don't know about you, but I only get a few minutes a day to debug software per day. I'm considering your post to be idle chatter, and moving into an off-topic manner.

Thorsten: "Given that, there is however a strange shortage of people who come up with fast and visually appealing rendering code."

Writing (low-level) code (for hardware) versus writing, is a much slower process for which I have performed and understand more so than some people who have published more code than I. (Everybody has they're forte within life, or strengths.) Writing source code dealing with 3D rendering is far more complex. To even to begin to code, the coder must have intimate knowledge of the hardware and source code. Very time consuming. Lets get back on topic. I just wasted 10 or so minutes scantly quickly reading what your wrote, in order to quickly reply here without wasting any of my precious time.
rogerx
 
Posts: 65
Joined: Sun Jan 08, 2012 9:39 am
Location: Conneaut, Ohio

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Thorsten » Thu Oct 15, 2015 4:32 pm

Have it your way. This is a waste of my time.
Thorsten
 
Posts: 11123
Joined: Mon Nov 02, 2009 8:33 am

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Hooray » Thu Oct 15, 2015 5:24 pm

since you are running fgfs inside gdb, you may want to check how to exactly your driver's vsync settings properly - i.e. there are flags that affect the driver, and others that affect osg/osgviewer (which fgfs is using internally).

Either way, I suggest to just swallow Thorsten's comments, because if you should be seriously interested in graphics/rendering related troubleshooting and benchmarking, there are not many other contributors around here who could help you as much as Thorsten unfortunately - in fact, even on the devel list, there are very few contributors actively involved with a comparable track record in graphics, so it would be a good idea to decide for yourself if it's worth the hassle.

Besides, it might be a good start to document your debugging settings on the wiki, to help others wanting to do similar things (many contributors are not too familiar with using tools like gdb, valgrind or GL/GLSL profilers)
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby rogerx » Thu Oct 15, 2015 6:04 pm

Hooray: I think I understand mine and Thorsten's discussion above, and I just do not have the time here to argue over semantics or perceptions, etc. With that stated, I respect others contributions and understand nobody is perfect, and each of us has our strengths. Sometimes there's conflict, and like many times, it's best just to let things be.

Now back to the thread, good point concerning with using gdb for checking vsync, but I "think" the reason FlightGear wasn't picking up the driver's vsync was due to not restarting Xorg for some odd reason after enabling the option within NVIDIA's Settings application. (This would be an upstream issue with the NVIDIA driver, or something on my system.) And now as I'm re-reading through NVIDIA variables, I may still be getting settings confused. Arg. Anyways, FlightGear has been, for the past day, limited to 60 frames per second. (ie. If frames render faster than the display/monitor, even intermittently, the application is just wasting CPU and/or GPU cycles. I'm pretty sure I'm on the ball on this one!)

And with your last sentence, that is my intent to document (ie. Setup TrackIR) for others that may find confusing. Forgive my ignorance, I only get a few minutes. As Winter arrives, I'll maybe have more time.
rogerx
 
Posts: 65
Joined: Sun Jan 08, 2012 9:39 am
Location: Conneaut, Ohio

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Bug Bunny » Sat Oct 24, 2015 10:40 pm

Thorsten wrote in Wed Oct 14, 2015 4:52 pm:
I think flightgear has a bottleneck problem/bug someplace within a pipeline someplace. Too many frame rates, and frame rates significantly drop.


That last sentence doesn't make a lot of sense.

In general, I would advise you to not post speculations on what causes the framerates you observe unless you have pretty solid test data and the context knowledge to interpret it - there are people in the forum who actually know these things really well.


He probably means he got for example, solid 60 fps, but for some instants it has stutter that is noticable by the eye, you can say it other way, frames are rendered like this in ms:
16ms (that is 60FPS)
16ms
16ms
16ms
100ms (bum!)
16ms
16ms
16ms

Stutter can be measured by FRAPS, what I know, there are big stutters just after start when you look around, I call it "look-around stutter" (happens only few times after observing 360deg) and it is pretty old problem (2010 or so).
Bug Bunny
 
Posts: 41
Joined: Tue Feb 24, 2015 4:00 pm
Location: Ukraine
Version: 3.6.0RC
OS: Windows 7

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby rogerx » Sun Oct 25, 2015 12:34 am

Bug Bunny: A very good explanation.

I would like to speculate that I may have noticed some slow frame rates still, but only when looking through the windows of the cockpit. But again, this is kind of speculation, as there are a lot more variables to consider. Another method I just recalled, turning off the 3D cockpit view might further narrow the cause down. (Oh, now I see the meaning of "3D cockpit" view! 3D cockpit view is likely defined by the interior view, including windows, panels, seats, etc... ) I appear to be very close to a usable FlightGear experience with having modest hardware here, as should be expected. Well any ways, I have (real) house work to complete before Winter, before I can sit and play, or tinker, with the computer.)
rogerx
 
Posts: 65
Joined: Sun Jan 08, 2012 9:39 am
Location: Conneaut, Ohio

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Hooray » Sun Oct 25, 2015 4:52 pm

this is what is commonly called "frame spacing" around here, and there's a fairly detailed explanation on the wiki covering the whole topic (see the system monitor article), including a whole article dedicated to explaining the most likely culprit (Nasal garbage collection) and what can be done about that
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby rogerx » Sun Oct 25, 2015 8:38 pm

Ah. We might be getting somewhere here blaming Nasal code. ;-)

We could always consult with Intel (and other CPU engineers) to create an optimized register specifically for only executing nasal code. (ie. Something like SSE/MMX ...)

Within some simulation games, I've seen where only a few critical gauges were employed, versus a dozen or so. (Now I likely know why there are few gauges within some simulations.) And some gauges do not require a 60Hz refresh from checking to see if they're merrily on or off. (ie. Prioritize gauges based on a lower priority refresh rate, as well as more distant objects also do not likely need a high refresh rate.)
rogerx
 
Posts: 65
Joined: Sun Jan 08, 2012 9:39 am
Location: Conneaut, Ohio

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby LesterBoffo » Mon Oct 26, 2015 3:47 pm

A few of us are using 5:4 ratio monitors which I believe don't need as much rendering power because of their less field of view, ( depending on FoV zoom of course..) My rig is a old economy gaming rig from 2010. I chose the EVGA GT430 GPU because of it's low power overhead, but it's pretty limited when flying in detailed terrain and with airports like LOWI and other Alpine/SouthernGermany Eastern France areas.

Oddly enough with though some of Marc's Lake of Constance motor GP race courses in 2.0 scenery I don't see as big a frame rate hit with all the extra scenery items.
User avatar
LesterBoffo
 
Posts: 2105
Joined: Sun Oct 02, 2011 4:02 pm
Location: Western USA
Callsign: LesBof
Version: 2016.1
OS: WinXP 32 bit

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Hooray » Tue Oct 27, 2015 8:36 pm

rogerx wrote in Sun Oct 25, 2015 8:38 pm:Ah. We might be getting somewhere here blaming Nasal code. ;-)

We could always consult with Intel (and other CPU engineers) to create an optimized register specifically for only executing nasal code. (ie. Something like SSE/MMX ...)


Nasal is implemented as a stack machine - what you suggest has basically been tried (and done) when Lua was ported to a pseudo-register VM. And there are some pretty good technical articles on the whole effort.

(Google v8/JavaScript is another assembly-language based VM)

However, Nasal's performance issues are not primarily due to it being a stack machine based VM, but due to the way its garbage collector is implemented, which is responsible for managing memory - without people having to worry about "leaks".

To learn more, see: http://wiki.flightgear.org/How_the_Nasal_GC_works

It is definitely possible to extend/improve the Nasal GC engine, and some of us have not just toyed with the idea, but even came up with patches for new experimental features - however, none of those were committed by any core developers, despite having been posted on the devel list.

Admittedly, implementing a completely new GC scheme is relatively involved, but it would be relatively straightforward to turn the existing GC scheme into a generational one - equally, there are existing GC libraries that implement incremental, generational and concurrent GCs for different purposes.

These are open source libs, compatible with the GPL - so could be used in FG/SG (LGPL).

Java is a language that supports a plethora of GC modes/schemes.

In general, the lowest-hanging fruit is improving the GC scheme to provide an optional GC mode next to the existing one, possibly by coming up with an abstract interface to integrate other GCs for testing purposes.

However, there are really only 3-4 people sufficiently familiar with the Nasal engine, most of them not even involved in core development, and most core developers are very much hesitant to touch this part of the engine for a number of reasons (Nasal not being actively maintained).

Given the existing backlog of patches and merge requests, most potential contributors who may work on the GC are apparently not very eager to spend our time on yet another effort that may end up being disregarded (myself included).

The other thing you mentioned (differently prioritized simulation entities) is already implemented at the SGSubsystem level.
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby rogerx » Tue Oct 27, 2015 11:38 pm

Some really good information, and I completely understand.

I would hate to get involved with something, only to break it more. But nor does this help the situation to simply ignore patches. I realize writing patches requires enormous amounts of time just to right one patch, not to also mention all the required research to understand the hardware and software specifications just to begin writing the patch. Hence, writing a patch to see it simply ignored on the mailing list sure drives a good spike into somebody.

Another angle, could be some core developers already have a solution, or know the specific problem more in depth. Or I previously speculated, afraid to break something they do not completely understand.

I don't know about anybody else, but I'm a strong believer in C (and maybe a little C++) and other Linux core scripting utilities. Java and Python, do not peak my interest due to politics and my own benchmarking on my systems here.
rogerx
 
Posts: 65
Joined: Sun Jan 08, 2012 9:39 am
Location: Conneaut, Ohio

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby hamzaalloush » Tue Oct 27, 2015 11:48 pm

man... how i would love for this GC issue to solved, then there will be no performance bottlenecks to Nasal scripting and you can use it without worrying..
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Hooray » Wed Oct 28, 2015 5:26 am

rogerx wrote in Tue Oct 27, 2015 11:38 pm:I don't know about anybody else, but I'm a strong believer in C (and maybe a little C++) and other Linux core scripting utilities. Java and Python, do not peak my interest due to politics and my own benchmarking on my systems here.


Nasal is primarily used by fgdata/middleware developers, not by core developers: http://wiki.flightgear.org/Nasal_success_stories

And programming in C/C++ requires a different set of skills - particularly when it comes to memory management.

Still, FG does contains tons of memory leaks, but also race conditions and segfaults - which is typically why Nasal programmers don't use C or C++ to implement their features, but opt for Nasal scripting instead.

It would be possible to come up with alternate GC schemes and implement those as an OPTION next to the existing GC - but there really is just a handful of people actively involved in the project who are intimately familiar with Nasal internals - most of them not core developers, and patches related to the internals of the Nasal engine (including the GC) have not seen much feedback so far.

In general, the GC is a crucial module obviously, but it also is well-encapsulated, i.e. there is basically only a single SMALL file that needs to be modified in order to improve the Nasal GC - and it would be possible to come up with a generic interface for providing different GC options, too.
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Thorsten » Wed Oct 28, 2015 6:18 am

For the record, Nasal GC is one known reason why frame spacing may be uneven. There's several others as well (texture loading and mipmapping, model loading, AI traffic issues, uneven detail in the view frustrum...) - feel free to blame everything to Nasal in any particular case without investigation, but don't expect too many people to be impressed.
Thorsten
 
Posts: 11123
Joined: Mon Nov 02, 2009 8:33 am

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby erik » Wed Oct 28, 2015 8:18 am

One thing which is often done in Nasal is update everything in one single timer function. If this causes a lot of work to be done once in every n number of milliseconds this could cause uneven frame times.

Erik
erik
 
Posts: 1520
Joined: Thu Nov 01, 2007 1:41 pm

PreviousNext

Return to Release candidates

Who is online

Users browsing this forum: No registered users and 0 guests