Board index FlightGear Support Graphics

Flightgear doesn't use 100% of the workload and Fonts bug

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.

Flightgear doesn't use 100% of the workload and Fonts bug

Postby Saga » Tue Mar 04, 2014 5:11 pm

Hi everyone!

I also had this issue with the previous versions of this amazing game/simulator. Currently I use the 3.0.0.
When I set the graphics parameters to the highest values, fg become slow, I got a low framerate (15). It can seems normal but in fact, it use less of about 50% of the CPU workload and about 30% of the GPU.
Moreover, the framerate fall to 1fps when I watch in the cockpit the "blindsides".

An example :

Image

I had another issue. In the HUD (windows, menus), labels tend to be clipped. You can see this, on the previous image, in the rendering options window.
And that's more visible when I enable the atmospheric light scattering:

Image

These problems occur with any airport, any aircraft.

This is my computer caracteristics :

    Processor: Intel i5-3570K, 4 cores, 3.4Ghz
    Memory: 8GB, DDR3, 1866MHz, CL9
    Graphic card : Sapphire HD Radeon 7950 Vapor-X 3GB
    OS : Windows 7 64 bits
I also use a SSD which contains all the datas of fg.
As you see, I've a powerful computer and I think it's strange that I get a low framerate.
My computer can draw more complex scenes.

The command line:

Code (): Select all
C:\Program Files\FlightGear\bin\Win64\fgfs.exe
--fg-root=C:\Program Files\FlightGear\data
--fg-scenery=C:\Program Files\FlightGear\data\Scenery;C:\Program Files\FlightGear\scenery;C:\Program Files\FlightGear\terrasync
--aircraft=c172p
--control=joystick
--language=en
--enable-mouse-pointer
--enable-random-objects
--enable-auto-coordination
--enable-horizon-effect
--enable-enhanced-lighting
--enable-distance-attenuation
--enable-ai-models
--enable-ai-traffic
--enable-real-weather-fetch
--enable-clouds3d
--enable-fullscreen
--geometry=1920x1200
--bpp=32
--fov=70
--texture-filtering=16
--prop:/sim/rendering/multi-sample-buffers=1
--prop:/sim/rendering/multi-samples=4
--timeofday=noon
--enable-terrasync
--disable-fgcom

When I switch on/off the option to enable the atmospheric light scattering, I've no output in console.

For the first problem, it's maybe caused to a bad managing of the multi-threading. For the second, It's clearly a bug but is it known ?
Do I have to report it in the bugtracker ?

Thanks in advance and have a nice day!
Last edited by Saga on Tue Jun 17, 2014 7:37 pm, edited 1 time in total.
Saga
 
Posts: 69
Joined: Tue Mar 04, 2014 3:52 pm
Location: Loire-Atlantique, France
Callsign: F-G0z
Version: Git next
OS: Win7, ArchLinux x64

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Thorsten » Tue Mar 04, 2014 6:51 pm

For the second, It's clearly a bug but is it known ?


I've seen one report of this before, with menus improperly drawn in both ALS and Rembrandt. It seems that this is triggered by ALS but not caused by ALS, as ALS doesn't actually render the menu items in question. Moreover, since also Rembrandt seems to be able to trigger it which runs via a rather different rendering code, my suspicion was that this may be a driver issue, especially since in both cases a Radeon card was involved.


I don't know what measure GPU occupancy shows here - it's conceivable (i.e. happening here under some conditions) that the vertex pipeline is jammed and determines the framerate while the fragment pipeline runs largely idle. In the classic renderer with all settings maxed you may also be running a geometry shader if a terrain type triggering it is nearby - and these are very costly.

Not utilizing all CPU cores is in my opinion fairly normal if you max out graphical settings - the performance bottleneck is then rendering shader effects and there's nothing the CPU can really do to speed it up.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby anonymous2 » Wed Mar 05, 2014 1:03 am

.
Last edited by anonymous2 on Thu Oct 02, 2014 10:02 am, edited 1 time in total.
anonymous2
Retired
 
Posts: 49
Joined: Sun Jan 31, 2010 3:19 pm

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Thorsten » Wed Mar 05, 2014 7:48 am

Yeah, well, that makes it even weirder. Weather is a Nasal script which doesn't have *any* connection with rendering, it in fact uses the same set of shader effects than Basic Weather.

The only common these I can see is a resource shortage - when you enable something which demands more resources, it seems they're missing somewhere else and the menu starts corrupting. And it's always an ATI involved.

Did you guys try changing drivers?
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Saga » Wed Mar 05, 2014 2:40 pm

I've launched the game (version 3.0.0) on ArchLinux and I got the same issues. Low framerate, menus not drawn when the atmospheric light scattering is enabled. The GPU load don't grow up to 30%.

The command to know the GPU load:
Code (): Select all
aticonfig --od-getclocks

Default Adapter - AMD Radeon HD 7900 Series
Core (MHz) Memory (MHz)
Current Clocks : 500 1250
Current Peak : 850 1250
Configurable Peak Range : [300-1100] [150-1575]
GPU load : 0%

I've created a bash script to display these informations in a loop.

With unigine heaven, I get 99%, and I heard the fans but with fg I don't.

I also have the menus which are not drawn when I enable the atmospheric light scattering.
I use the proprietary driver catalyst 13.12.

I suspect the thread which take care of the OpenGL functions calls (the renderer) to do something else.
Just to test, I've create a simple program which contain just calls to glClearColor() without the v-sync and I also got 99% of activity.
And I agree with you about CPU cores load.

Do you know gdebugger ? I could have useful informations about the rendering in flightgear. If it can help... It works very well. :wink:
Host and maintainer of fgcom.flightgear.org.
Saga
 
Posts: 69
Joined: Tue Mar 04, 2014 3:52 pm
Location: Loire-Atlantique, France
Callsign: F-G0z
Version: Git next
OS: Win7, ArchLinux x64

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Thorsten » Wed Mar 05, 2014 3:40 pm

I suspect the thread which take care of the OpenGL functions calls (the renderer) to do something else.


Yeah, except these things aren't ever seen on NVIDIA cards... So try to explain that as well.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Hooray » Wed Mar 05, 2014 4:02 pm

Hi & welcome!

Saga wrote in Wed Mar 05, 2014 2:40 pm:Do you know gdebugger ? I could have useful informations about the rendering in flightgear. If it can help... It works very well. :wink:


If you know how to use gDebugger, please do post some results here, which would help us stop speculating.

FlightGear being GPU limited under some circumstances and CPU limited under others is a controversial topic and tends to cause flame wars, so I refrained from leaving a comment here, because Thorsten was already trying to help you. You can use the new draw-masks to disable things like terrain/scenery/clouds and see what performance you'll get then.
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: Flightgear doesn't use 100% of the workload and GUI clip

Postby imagio » Wed Mar 19, 2014 6:35 pm

I am having the same issues with GUI clipping. It happens with the default rendering scheme and gets much worse when ALS is enabled (almost no gui elements have text).

Specs:
FG 3.0 x64
i7 2600k
16gb ram
radeon 7870 2gb -- amd catalyst 14.2 driver
windows 8.1 x64
imagio
 
Posts: 33
Joined: Wed Mar 19, 2014 6:31 pm
Location: Pittsburgh
OS: Win 8.1

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Thorsten » Wed Mar 19, 2014 7:08 pm

Yep - another ATI weirdness. Three reported ATI cases now, no NVIDIA card.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Hooray » Wed Mar 19, 2014 7:12 pm

Try to use the startup profile detailed at: http://wiki.flightgear.org/Howto:Debugg ... ar_Crashes
If that doesn't solve the problem, you are probably facing a hardware/driver issue, which means that you may need to upgrade (or even downgrade) your drivers, and/or disable some settings on the driver side of things.
If however, the "minimal startup profile" stops the error from occuring, that would suggest that FG is using some "code paths" the are not supported by your current driver - this isn't all that uncommon, we have an increasing number of shaders, while most of the existing FG code was really only written with a fixed rendering pipeline in mind - and in fact, much of it even predates the OSG port, such as for example the GUI (PLIB/PUI). It isn't that far-fetched to think that these factors may not be very well supported under certain circumstances. In general, nvidia drivers are often understood to be/perform better (despite being closed-source).
It would also be interesting if any "modern" OSG code exhibits similar problems or not, to check that use any of the Canvas-based GUI dialogs/instruments for example, and please report back here.

In summary, our way of using OSG is not particularly optimized, and we're doing a lot of things that are known to be inefficient, such as having lots of GL state changes, and using legacy GL code in conjunction with more modern code - all of these things are having performance penalties, and they also affect compatibility - especially because GLSL, unlike DirectX shader code, is not bytecode, but compiled on-the-fly by your driver - in other words, each GPU vendor will typically have their own GLSL compiler implementation, and these are known to be fragile under certain circumstances - as an open source project, we do not have the resources to literally test each new -or modified- shader on all major hardware platforms - so we really rely on end-user feedback, but also on end-users being able -and willing to- read up on troubleshooting such issues, to provide better/more informed feedback, e.g. by using tools like gDebugger or the corresponding ATI/AMD and nvidia equivalents.

Writing portable cross-platform code is tricky in and of itself, but that problem is already solved by FlightGear - however, supporting different GPU vendors and makes is basically an identical challenge these days, because hardware, drivers and GLSL compilers differ hugely when it comes to quality and performance.

All that being said, there's a fairly detailed troubleshooting guide to be found in the wiki, and one of the first solutions suggested there is adjusting your bpp (desktop color depth), and disabling compositing (hardware accelerated desktop effects, including shaders)
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: Flightgear doesn't use 100% of the workload and GUI clip

Postby punkepanda » Wed Mar 19, 2014 7:57 pm

Thorsten, why dont you switch to ATI and see if your atitude switch with it.
Drivers is one part of the problem, but the biggest part of the problem is bad coding habits.

Its also true that Unigine is using its full potensiial in OpenGL mode. Tried it myself with all my ATI drivers on both NIX and crapOS 7 and 8. So the question is if its a FG coding issue or OSG code issue.. There is no other options! Face it :)

Other engines dont have thise so called driver issues. So something must be done bether in the core of FG or OSG as it seems that ATI wont do it for us
punkepanda
 
Posts: 234
Joined: Mon Nov 04, 2013 10:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Hooray » Wed Mar 19, 2014 8:58 pm

It's not as simple as that to be honest: FlightGear is a fairly old code base, and it also isn't particularly modern - these days, many parts are basically unmaintained, and haven't been touched in years, despite containing lots of legacy code. OSG is much more powerful than you may think, but it cannot magically fix all the problems that FlightGear introduces, we have a ton of features that basically still date back to the pre-OSG days, i.e. when we were using purely PLIB and SDL. OSG itself is generally rock-solid and there are rarely any issues found with it. To see for yourself, just run osgviewer or any of the OSG examples.
As I recently pointed out elsewhere, those OSG examples even support Intel GMA cards, often even shaders to some degree - but we have never really formalized the way OpenGL/OSG code is written/developed for FlightGear, including effects and shaders. And as I mentioned previously, writing portable shaders is made unnecessarily difficult due to the nature of GLSL itself, and due to the fact that we cannot easily develop/test things on different hardware. Most of us really only have 1-2 computers - typically, with nvidia hardware, specifically purchased for running FG and other 3D software.

This is a volunteer-driven project, you cannot really expect people to spend thousands of dollars on hardware that they don't need. Thorsten already spent more money on his particular notebook than 99% of our users probably, including core developers, and including myself. So it really isn't fair to suggest that all those shader problems are due to "bad coding habits".

First of all, you should really check if the error is in any way affected by NOT using shaders at all, if the error persists, it is is obviously unrelated.
Then again, it is even possible that there are bugs in the C++/OSG code in FG, and that the nvidia drivers just are more forgiving, or even just have better/more lenient (or aggressive) optimization techniques.

Yeah, it is true that most commercial games will perform rather well on modern hardware where FG may typically show single digit frame rates, and even crash - but that is unlikely to be due to GLSL/shaders at all. There are more factors involved here, outside the reach of people doing primarily Nasal/GLSL development.

To see for yourself, just run osgviewer or even fgviewer and see if certain errors show up or not. That is a good thing to do troubleshooting wise, and it is for us easier to check what MIGHT be going on.

I am not sure if this is just a "driver" issue - even if there's no problem on the driver side of things, it clearly is an incompatibility - regardless of the reason. Commercial projects typically have the manpower and resources to do lots of testing so that shaders and other code can be adjusted accordingly.

So far, this has not been a focus of the FlightGear project, and it is not reasonable to ask individual developers to handle this by suggesting that they should get certain hardware, and even pay for it ...

For example, I have access to 4 different computers, but I don't typically build/run/test FlightGear on all of them - even though I could do that, but there are more enjoyable things to do admittedly. Still, I try to provide the corresponding step-by-step instructions to tell people how to troubleshoot problems - but don't expect me to do all this on my own, let alone purchase additional hardware each month, just because someone may be running into certain issues.

What I've seen so far, could just as well be mis-configured and incompatible default ATI settings, i.e. anti-aliasing etc ...
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: Flightgear doesn't use 100% of the workload and GUI clip

Postby TheTom » Wed Mar 19, 2014 10:09 pm

That's definitely a problem with ATI. I've tried an HD 7870 on Windows as well as Linux with different driver versions, but all showed the same problems with different intensity (mainly flickering of some parts and other buffer contents) and different applications using OpenGL (eg. FlightGear, Blender, Spotify).
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby punkepanda » Wed Mar 19, 2014 11:30 pm

Great answer Hooray, as always. Ur community support is outstanding :) And im happy to see that you dont try do ignore or hide the issues.

I would really like to see this get fixed some how. As we cannot ignore that ATI has a big market and they have more power for less money (discussable).
And yes it is a really hard one to solve. i understand that this isnt something anybody can solve as it is as you say a long history of codebase from developers that probably many has left the project underways.

Fixing this ATI bugs along with using FULL potential of the CPU and GPU on both NVidia and ATI then think that FG would be in competition with the comercial simulators for many reasons. Manly because if its flexibility and that it has a contributing community. Graphics and eye candy im sure will come by time.

Uffcourse I dont expect or suggest that the developer should figure this out just by asking. I see its more as a recomended priority and a big challenge. As it is not just the ATI issue, but also bad FPS in too many areas. To much memory use also (that we all know).

I just try to make a point out of the bottlenecks that we all suffer from.

Besides that there are many nice stuff going on from day to day. Thorsteins new cloud is really cool and ads more of that nice realism.

Still I think that a deeper look into the core is important before adding alot of new stuff that further make it to slow for a avarage computer.
But we all are good at different areas I guess.

BTW ATI realesed new beta drivers 2 days ago.. Gonna try them and see if it makes any difference, still I doubt it :)
punkepanda
 
Posts: 234
Joined: Mon Nov 04, 2013 10:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby TheTom » Wed Mar 19, 2014 11:57 pm

While working on the new GUI based on Canvas I have not noticed any problems so far, so it should not suffer from the clipping problems.
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Next

Return to Graphics

Who is online

Users browsing this forum: No registered users and 4 guests