Troubleshooting crashes: Difference between revisions

Jump to navigation Jump to search
m
→‎Performance Issues: http://forum.flightgear.org/viewtopic.php?f=37&t=22309&p=202574&hilit=amd+load#p203655
m (→‎Crashes in general: http://forum.flightgear.org/viewtopic.php?f=37&t=22309&p=202574&hilit=amd+load#p203650)
m (→‎Performance Issues: http://forum.flightgear.org/viewtopic.php?f=37&t=22309&p=202574&hilit=amd+load#p203655)
Line 28: Line 28:


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.
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.
Some people have been suggesting to our core/shaders developers to switch to AMD/ATI or even Intel hardware in order to get rid of certain problems.
But 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 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 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 contributors 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. Some of our shader developers already spent more money on certain hardware than 99% of our users probably, including core developers. 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.


== Possible causes ==
== Possible causes ==

Navigation menu