User:Hooray/SandBox/FlightGear Performance and Run-Time Footprint Debate: Difference between revisions
m (Hooray moved page FlightGear Performance and Run-Time Footprint Debate to User:Hooray/SandBox/FlightGear Performance and Run-Time Footprint Debate without leaving a redirect: this is causing too much noise) |
m (Switch to the {{forum url}} and {{forum link}} templates for all forum links.) |
||
Line 10: | Line 10: | ||
<br/> | <br/> | ||
Right from the beginning, I suggested that we shouldn't restrict our focus to a single cause (like v2.0 scenery in this case) but look at the bigger picture, i.e. what needs to be done to identify certain issues earlier (regardless of their manifestation), but also to enable non-contributors to make better, and more informed, bug reports. | Right from the beginning, I suggested that we shouldn't restrict our focus to a single cause (like v2.0 scenery in this case) but look at the bigger picture, i.e. what needs to be done to identify certain issues earlier (regardless of their manifestation), but also to enable non-contributors to make better, and more informed, bug reports. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214201}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 21: | Line 21: | ||
<br/> | <br/> | ||
But we won't ever resolve them by saying 'The project is going into a bad direction.' The only way to solve them is constructively - establish the facts of what is actually going wrong. Trying to understand whether things can be fixed in the current framework, whether existing settings need to be exposed better, whether we lack information, or whether new development is needed. If it's the latter, make a good case for that new development and convince the people who matter. Document in the wiki what you found out can be done. Blanket-bashing the project won't help. Complaining that X is broken without providing the info necessary to fix it won't help. Making claims that feature X is causing a problem without having any evidence won't help. Ascribing opinions to developers which never have been said won't help. | But we won't ever resolve them by saying 'The project is going into a bad direction.' The only way to solve them is constructively - establish the facts of what is actually going wrong. Trying to understand whether things can be fixed in the current framework, whether existing settings need to be exposed better, whether we lack information, or whether new development is needed. If it's the latter, make a good case for that new development and convince the people who matter. Document in the wiki what you found out can be done. Blanket-bashing the project won't help. Complaining that X is broken without providing the info necessary to fix it won't help. Making claims that feature X is causing a problem without having any evidence won't help. Ascribing opinions to developers which never have been said won't help. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214060}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 30: | Line 30: | ||
{{FGCquote | {{FGCquote | ||
|The lesson I take from all this (and related discussions) that I will be in the future very careful to make any rendering code available on GIT which isn't guaranteed fool-proof and might lead to less than perfect visual sometimes. If the general mood is that we bash the project for a release early, release often policy, then I will stop with it. | |The lesson I take from all this (and related discussions) that I will be in the future very careful to make any rendering code available on GIT which isn't guaranteed fool-proof and might lead to less than perfect visual sometimes. If the general mood is that we bash the project for a release early, release often policy, then I will stop with it. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214060}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 41: | Line 41: | ||
But these days, we're simply lacking the manpower to do so.)<br/> | But these days, we're simply lacking the manpower to do so.)<br/> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214064}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 54: | Line 54: | ||
<br/> | <br/> | ||
I'd agree that we do have a real problem, but I'd say it's not necessarily in the graphics department - but ultimately, we really need to add better diagnostics, i.e. some kind of '''task monitor''' that tells us where time/horse power and RAM are spent. | I'd agree that we do have a real problem, but I'd say it's not necessarily in the graphics department - but ultimately, we really need to add better diagnostics, i.e. some kind of '''task monitor''' that tells us where time/horse power and RAM are spent. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213965}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 66: | Line 66: | ||
<br/> | <br/> | ||
I understand, much of the computations are purely for optical reasons, and that's what a GPU is there for. But why not take some of it, and put it to idle CPU's? I'm running on a dual-core machine, knowing of this, I'd expect on the same hardware, but with a 8core CPU the same results; just because I have 8 CPU's running on 12% instead of 2 running on 50% doesn't seem to take any load off the GPU. Theoretically - and as I understand things. | I understand, much of the computations are purely for optical reasons, and that's what a GPU is there for. But why not take some of it, and put it to idle CPU's? I'm running on a dual-core machine, knowing of this, I'd expect on the same hardware, but with a 8core CPU the same results; just because I have 8 CPU's running on 12% instead of 2 running on 50% doesn't seem to take any load off the GPU. Theoretically - and as I understand things. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=181564}} | ||
|title=<nowiki>Can FG computations be made more balanced?</nowiki> | |title=<nowiki>Can FG computations be made more balanced?</nowiki> | ||
|author=<nowiki>chris_blues</nowiki> | |author=<nowiki>chris_blues</nowiki> | ||
Line 77: | Line 77: | ||
One day the game runs fine, then a 777-S is added and there goes my 4 GiB of RAM. It's a very nice aircraft but it consumes too much ram, not even the 777 PMDG consumes that amount.<br/> | One day the game runs fine, then a 777-S is added and there goes my 4 GiB of RAM. It's a very nice aircraft but it consumes too much ram, not even the 777 PMDG consumes that amount.<br/> | ||
But mostly I didn't bother too much with this, so I compiled again from git and then my fps goes to 3 even while flying the 737. I would assume it's something related to the scenery, but I don't know much about anything. It stays at 3 for dozens of seconds then goes to 40-50, but then after a few seconds it drops again to 3-5 and stays there. | But mostly I didn't bother too much with this, so I compiled again from git and then my fps goes to 3 even while flying the 737. I would assume it's something related to the scenery, but I don't know much about anything. It stays at 3 for dozens of seconds then goes to 40-50, but then after a few seconds it drops again to 3-5 and stays there. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213961}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>junior-s</nowiki> | |author=<nowiki>junior-s</nowiki> | ||
Line 86: | Line 86: | ||
{{FGCquote | {{FGCquote | ||
|I'd love to have the money to buy a new pc and use it for many things and Flightgear, but I don't. I also don't think most people flying a free Simulator have the required computer power to run the game as it's requesting since about 2 years ago, but since I have a choice of either spending lots of money to buy a new PC just for Flightgear (because all of my other 54 games run fine at High settings) or buy a payware simulator, I chose to buy a simulator that runs fine with my current hardware. | |I'd love to have the money to buy a new pc and use it for many things and Flightgear, but I don't. I also don't think most people flying a free Simulator have the required computer power to run the game as it's requesting since about 2 years ago, but since I have a choice of either spending lots of money to buy a new PC just for Flightgear (because all of my other 54 games run fine at High settings) or buy a payware simulator, I chose to buy a simulator that runs fine with my current hardware. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213961}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>junior-s</nowiki> | |author=<nowiki>junior-s</nowiki> | ||
Line 95: | Line 95: | ||
{{FGCquote | {{FGCquote | ||
|I don't need to max everything in order not to be able to play it. The default settings by themselves are enough to make the game unplayable, at least on Linux. FG's memory consumption is high and the scenery is too detailed. Either that, or it's a combo of mistakes that make the game not work for everybody. For instance, I saw a picture in this forum showing a part of the scenery: it was formed of what, little squares of 40x40cm? Even smaller? That might be OK in short distances but the screenshot (for what I can remember) showed the scenery as quite far. No one gives that much attention to ground level details, no one will zoom out till they can see ants on the ground. | |I don't need to max everything in order not to be able to play it. The default settings by themselves are enough to make the game unplayable, at least on Linux. FG's memory consumption is high and the scenery is too detailed. Either that, or it's a combo of mistakes that make the game not work for everybody. For instance, I saw a picture in this forum showing a part of the scenery: it was formed of what, little squares of 40x40cm? Even smaller? That might be OK in short distances but the screenshot (for what I can remember) showed the scenery as quite far. No one gives that much attention to ground level details, no one will zoom out till they can see ants on the ground. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213977}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>junior-s</nowiki> | |author=<nowiki>junior-s</nowiki> | ||
Line 104: | Line 104: | ||
{{FGCquote | {{FGCquote | ||
|In fact I tested X-Plane and it works so well I couldn't believe, because the developers say "use 16GB of RAM and multiple processors". That's not quite the case, as I spoke to one of it's developers he/she said the game auto-adjusts itself to the hardware it's been run on. But even so, I didn't notice any difference from the ad videos they put up on Youtube. | |In fact I tested X-Plane and it works so well I couldn't believe, because the developers say "use 16GB of RAM and multiple processors". That's not quite the case, as I spoke to one of it's developers he/she said the game auto-adjusts itself to the hardware it's been run on. But even so, I didn't notice any difference from the ad videos they put up on Youtube. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213978}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>junior-s</nowiki> | |author=<nowiki>junior-s</nowiki> | ||
Line 114: | Line 114: | ||
{{FGCquote | {{FGCquote | ||
|The numbers say that without any doubt, 2.0 scenery is what uses all the memory, nothing else - not hires textures, not trees. | |The numbers say that without any doubt, 2.0 scenery is what uses all the memory, nothing else - not hires textures, not trees. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214100}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 123: | Line 123: | ||
{{FGCquote | {{FGCquote | ||
|Do not use the 2.0 scenery (because it is an early, imperfect work in progress release) and watch the issues disappear. I confirmed with my 'Yeah, pretty much' that I recommend putting up a warning that you need lots of memory to use the 2.0 scenery and that I would recommend stay with 1.0 if you don't have that. | |Do not use the 2.0 scenery (because it is an early, imperfect work in progress release) and watch the issues disappear. I confirmed with my 'Yeah, pretty much' that I recommend putting up a warning that you need lots of memory to use the 2.0 scenery and that I would recommend stay with 1.0 if you don't have that. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214050}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 132: | Line 132: | ||
{{FGCquote | {{FGCquote | ||
|I don't think it's fair to blame any particular subsystem for these issues. The fact is, the project has to keep evolving and transforming in order to remain relevant, and this means things can sometimes break in the process, regressions rear ugly heads, some users become unhappy, but overall the project is moving forward and commits are regularly made by core contributions, which I think at some point becomes essential to maintain confidence in the future of the project, as we can see in many other open-source code bases, rather than stagnate and become increasingly irrelevant in today's fast moving market, as it's never a good idea to throw away perfectly good opportunities for progress, even though it could inspire distrust and even drive away some potential users, as long as the core contributors are kept reasonably satisfied and are not compelled to move away from the project. | |I don't think it's fair to blame any particular subsystem for these issues. The fact is, the project has to keep evolving and transforming in order to remain relevant, and this means things can sometimes break in the process, regressions rear ugly heads, some users become unhappy, but overall the project is moving forward and commits are regularly made by core contributions, which I think at some point becomes essential to maintain confidence in the future of the project, as we can see in many other open-source code bases, rather than stagnate and become increasingly irrelevant in today's fast moving market, as it's never a good idea to throw away perfectly good opportunities for progress, even though it could inspire distrust and even drive away some potential users, as long as the core contributors are kept reasonably satisfied and are not compelled to move away from the project. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214281}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>adrian</nowiki> | |author=<nowiki>adrian</nowiki> | ||
Line 142: | Line 142: | ||
|The scenery doesn't have a LOD system yet, yes. I gather the philosophy was we need a viable scenery first before we can simplify it down to implement a LOD system - so we have the first step done, and the second is in progress. What you're upset about is that the second step isn't done yet and the scenery team was stupid enough to listen to people like me and gave us what they had so far. But people needed to start with the first. <br/> | |The scenery doesn't have a LOD system yet, yes. I gather the philosophy was we need a viable scenery first before we can simplify it down to implement a LOD system - so we have the first step done, and the second is in progress. What you're upset about is that the second step isn't done yet and the scenery team was stupid enough to listen to people like me and gave us what they had so far. But people needed to start with the first. <br/> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214074}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 151: | Line 151: | ||
{{FGCquote | {{FGCquote | ||
|There's nothing wrong with FG as far as I know - it will probably run fine on your computer and deliver quite decent visuals if you customize it. There's a lot wrong with the way the information how to customize it to your needs is documented and transmitted. And this is where the republic of heaven thing could come in - rather than complain and write support PNs for the kingdom to come, you (all) could help to assemble, improve and spread this information. | |There's nothing wrong with FG as far as I know - it will probably run fine on your computer and deliver quite decent visuals if you customize it. There's a lot wrong with the way the information how to customize it to your needs is documented and transmitted. And this is where the republic of heaven thing could come in - rather than complain and write support PNs for the kingdom to come, you (all) could help to assemble, improve and spread this information. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214074}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 160: | Line 160: | ||
{{FGCquote | {{FGCquote | ||
|I had banned myself from KSFO because I would get to swap even before seeing anything and now I tried and fgfs starts and is usable in my 32 bit debian system with <span style{{=}}"font-size: 150%; line-height: normal">2GB of RAM</span>. Simple planes and no multiplayer though, but is really great improvement. | |I had banned myself from KSFO because I would get to swap even before seeing anything and now I tried and fgfs starts and is usable in my 32 bit debian system with <span style{{=}}"font-size: 150%; line-height: normal">2GB of RAM</span>. Simple planes and no multiplayer though, but is really great improvement. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214113}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>sa7k</nowiki> | |author=<nowiki>sa7k</nowiki> | ||
Line 171: | Line 171: | ||
<br/> | <br/> | ||
But to run the 2.0 scenery in its current state (which is, as I repeatedly said, an early work in progress release which the scenery team was reluctant to do) you do, and my recommendation is to stay clear of it till the issues (zero area triangles, LOD,...) are resolved. | But to run the 2.0 scenery in its current state (which is, as I repeatedly said, an early work in progress release which the scenery team was reluctant to do) you do, and my recommendation is to stay clear of it till the issues (zero area triangles, LOD,...) are resolved. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214050}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 184: | Line 184: | ||
<br/> | <br/> | ||
But it matters what is actually wrong with the 2.0 scenery - you still can't say that it's made of 40x40 cm squares, because that is not its problem. You can't say that X is wrong with it when it's in fact Y just because something is wrong. | But it matters what is actually wrong with the 2.0 scenery - you still can't say that it's made of 40x40 cm squares, because that is not its problem. You can't say that X is wrong with it when it's in fact Y just because something is wrong. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214050}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 195: | Line 195: | ||
<br/> | <br/> | ||
It'd be nice to have that choice made semi-automatically (I'd still like to customize it), but the question remains - FG allows you to focus on what is important for you. Whether you see an issue or not depends on what choice you're trying to make and how it is supported by hardware. | It'd be nice to have that choice made semi-automatically (I'd still like to customize it), but the question remains - FG allows you to focus on what is important for you. Whether you see an issue or not depends on what choice you're trying to make and how it is supported by hardware. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214050}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 206: | Line 206: | ||
<br/> | <br/> | ||
Using the 2.0 scenery (or in fact any scenery) is '''optional'''. And you should in fact ''not'' do it if you think you're low on memory. I think that recommendation is now all over the place in the forum, on the FG site and on the mailing list. We still provide the 1.0 lowres scenery for download and probably will continue to do so for a while. And if memory is the bottleneck (an extended period of low framerate jumping back to 50 sure looks like the system starting to use swap...) you can use high graphics settings and create lots of details procedurally. | Using the 2.0 scenery (or in fact any scenery) is '''optional'''. And you should in fact ''not'' do it if you think you're low on memory. I think that recommendation is now all over the place in the forum, on the FG site and on the mailing list. We still provide the 1.0 lowres scenery for download and probably will continue to do so for a while. And if memory is the bottleneck (an extended period of low framerate jumping back to 50 sure looks like the system starting to use swap...) you can use high graphics settings and create lots of details procedurally. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213972}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 217: | Line 217: | ||
<br/> | <br/> | ||
The 'simulator that runs fine with your current hardware' has probably just the same feature - if you would feed it hires data for terrain and aircraft, it'd consume more resources than you have. | The 'simulator that runs fine with your current hardware' has probably just the same feature - if you would feed it hires data for terrain and aircraft, it'd consume more resources than you have. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213972}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 226: | Line 226: | ||
{{FGCquote | {{FGCquote | ||
|An obvious case is scenery 2.x. Yes it is heavy, yes it is released early (understandably as Thorsten argues), yes one can warn people to revert to 1.x temporarily. But do not leave it at that. Maybe there is being worked hard at smart solutions, but that is not really becoming obvious to people that read the forum. Understandably they get frustrated by that. | |An obvious case is scenery 2.x. Yes it is heavy, yes it is released early (understandably as Thorsten argues), yes one can warn people to revert to 1.x temporarily. But do not leave it at that. Maybe there is being worked hard at smart solutions, but that is not really becoming obvious to people that read the forum. Understandably they get frustrated by that. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214004}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>KL-666</nowiki> | |author=<nowiki>KL-666</nowiki> | ||
Line 237: | Line 237: | ||
<br/> | <br/> | ||
Well maybe there is already being worked on this kind of optimization. | Well maybe there is already being worked on this kind of optimization. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214004}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>KL-666</nowiki> | |author=<nowiki>KL-666</nowiki> | ||
Line 252: | Line 252: | ||
<br/> | <br/> | ||
The story of course continues, because in their infinite wisdom, the powers to be made the 2.0 scenery the default via terrasync and did in fact for some undisclosed reason not insert a statement into the release announcement that it's heavy on memory, and I've been spending tens of hours by now to make that bit of info more widely known. So the whole way the 3.0 release went with the 2.0 scenery and the information about potential problems was a royal clusterf*&^% | The story of course continues, because in their infinite wisdom, the powers to be made the 2.0 scenery the default via terrasync and did in fact for some undisclosed reason not insert a statement into the release announcement that it's heavy on memory, and I've been spending tens of hours by now to make that bit of info more widely known. So the whole way the 3.0 release went with the 2.0 scenery and the information about potential problems was a royal clusterf*&^% | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213983}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 261: | Line 261: | ||
{{FGCquote | {{FGCquote | ||
|I'm getting seriously frustrated about the whole scenery thing. About the release management which discarded all the good evidence about memory issues. About users who can't find it in them to cut the scenery people some slack and acknowledge that the 2.0 scenery is a step towards something better - not the end product, but something to work with while something new is rolled out, and that using 1.0 apparently isn't an option. About the misinformation that is spread because people can't be bothered to verify information. About long term contributors who run around and claim that we have a huge problem in the code, when in fact all investigations have shown that most issues go away when reverting to 1.0 scenery. And about the general notion that nobody would care about the whole thing, when in fact plenty of people are working on the issues. | |I'm getting seriously frustrated about the whole scenery thing. About the release management which discarded all the good evidence about memory issues. About users who can't find it in them to cut the scenery people some slack and acknowledge that the 2.0 scenery is a step towards something better - not the end product, but something to work with while something new is rolled out, and that using 1.0 apparently isn't an option. About the misinformation that is spread because people can't be bothered to verify information. About long term contributors who run around and claim that we have a huge problem in the code, when in fact all investigations have shown that most issues go away when reverting to 1.0 scenery. And about the general notion that nobody would care about the whole thing, when in fact plenty of people are working on the issues. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213983}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 270: | Line 270: | ||
{{FGCquote | {{FGCquote | ||
|Making scenery is a completely different branch of coding from rendering scenery. Even if I would not add any more rendering options, I would have zero qualification working on scenery. You can't simply assume that you can reassign people to any task - a 3d modeler isn't going to be a coder if you ask him to, a graphics artist isn't going to become a rendering specialist. Within each area of specialization, people do fix bugs before adding options. | |Making scenery is a completely different branch of coding from rendering scenery. Even if I would not add any more rendering options, I would have zero qualification working on scenery. You can't simply assume that you can reassign people to any task - a 3d modeler isn't going to be a coder if you ask him to, a graphics artist isn't going to become a rendering specialist. Within each area of specialization, people do fix bugs before adding options. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213983}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 280: | Line 280: | ||
{{FGCquote | {{FGCquote | ||
|Memory footprint has been a recurring theme on the mailing list and Rebecca has demonstrated it to be almost exclusively relate to the scenery. The scenery team is busy getting rid of extra zero area triangles for the next scenery release. James has pushed the changes to the tile cache for better memory footprint. People are working on a terrain LOD scheme. Prior to the 3.0 release, you can find my messages pushing for a clear statement that the 2.0 scenery as is is rather memory intense and that we recommend it should only be used on systems with plenty of memory and that we should keep the 1.0 scenery available. There are forum messages by yours truly all over the place explaining that the first measure in case of any trouble with FG 3.0 out of the box should be to revert to the old scenery. | |Memory footprint has been a recurring theme on the mailing list and Rebecca has demonstrated it to be almost exclusively relate to the scenery. The scenery team is busy getting rid of extra zero area triangles for the next scenery release. James has pushed the changes to the tile cache for better memory footprint. People are working on a terrain LOD scheme. Prior to the 3.0 release, you can find my messages pushing for a clear statement that the 2.0 scenery as is is rather memory intense and that we recommend it should only be used on systems with plenty of memory and that we should keep the 1.0 scenery available. There are forum messages by yours truly all over the place explaining that the first measure in case of any trouble with FG 3.0 out of the box should be to revert to the old scenery. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213983}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 294: | Line 294: | ||
<br/> | <br/> | ||
So it's unlikely that utilizing your idle CPUs for rendering would make more than a dent - especially if you imagine the data flow back and forth you create. Just try running FG with software rendering only and see how your 8 cores keep up with the performance of the GPU :-) Or, if the above benchmark is true, you could run at 108% max. instead of 100% - not really that impressive, is it? | So it's unlikely that utilizing your idle CPUs for rendering would make more than a dent - especially if you imagine the data flow back and forth you create. Just try running FG with software rendering only and see how your 8 cores keep up with the performance of the GPU :-) Or, if the above benchmark is true, you could run at 108% max. instead of 100% - not really that impressive, is it? | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=181606}} | ||
|title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 303: | Line 303: | ||
{{FGCquote | {{FGCquote | ||
|on a high-end GPU (which I assume you have), the single determining factor for the framerate seems to be the vertex count of clouds, buildings and trees (in this order). So rendering overcast sky makes a huge difference to rendering clear sky, rendering a city worth of random buildings makes a huge difference to rendering a desert, and rendering dense forests makes a difference to rendering a few patches of green. With all details to max, we probably burn 99% of the total computational load in rendering (it's about 1200 lines of instructions per pixel 30-60 times per second), all other flight related tasks like computing aerodynamics are small in comparison. | |on a high-end GPU (which I assume you have), the single determining factor for the framerate seems to be the vertex count of clouds, buildings and trees (in this order). So rendering overcast sky makes a huge difference to rendering clear sky, rendering a city worth of random buildings makes a huge difference to rendering a desert, and rendering dense forests makes a difference to rendering a few patches of green. With all details to max, we probably burn 99% of the total computational load in rendering (it's about 1200 lines of instructions per pixel 30-60 times per second), all other flight related tasks like computing aerodynamics are small in comparison. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=181606}} | ||
|title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 314: | Line 314: | ||
<br/> | <br/> | ||
So you can move the rest wherever you want - since it's not determining my framerate in its 'bad' structure now, it will not determine my framerate in an optimized structure either. That may not be the situation on the machine Mathias is on, and Mathias may not be interested in the same rendering setup as I am - but that's how it works on my machine right now | So you can move the rest wherever you want - since it's not determining my framerate in its 'bad' structure now, it will not determine my framerate in an optimized structure either. That may not be the situation on the machine Mathias is on, and Mathias may not be interested in the same rendering setup as I am - but that's how it works on my machine right now | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=181608}} | ||
|title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 325: | Line 325: | ||
<br/> | <br/> | ||
The graphics card on the other hand has parallel rendering pipelines in the first place. | The graphics card on the other hand has parallel rendering pipelines in the first place. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=153266}} | ||
|title=<nowiki>Re: [SUGGESTION] Multi-core FlightGear support</nowiki> | |title=<nowiki>Re: [SUGGESTION] Multi-core FlightGear support</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 336: | Line 336: | ||
<br/> | <br/> | ||
Which doesn't really mean that anybody in particular would be wrong here, but originally the FG main loop was designed to be a single sequential loop that scaled roughly with the frequency of the CPU - which is why someone running FG on a "high-end" gaming computer today may very well have the impression that FG's architecture is not the problem, especially because of the number of background threads already added over time and now working behind the scenes, which ALREADY make use of additional cores to reduce the footprint of the main loop. | Which doesn't really mean that anybody in particular would be wrong here, but originally the FG main loop was designed to be a single sequential loop that scaled roughly with the frequency of the CPU - which is why someone running FG on a "high-end" gaming computer today may very well have the impression that FG's architecture is not the problem, especially because of the number of background threads already added over time and now working behind the scenes, which ALREADY make use of additional cores to reduce the footprint of the main loop. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=181613}} | ||
|title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 349: | Line 349: | ||
<br/> | <br/> | ||
There's a reason why software companies tend to keep lots of hardware around, to do tests and benchmarks on old/common hardware. | There's a reason why software companies tend to keep lots of hardware around, to do tests and benchmarks on old/common hardware. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=181613}} | ||
|title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 366: | Line 366: | ||
I am certainly no developer myself but I understand that it would take a mammoth effort to modify FG's core to better support multi-cores and other resources effectively.<br/> | I am certainly no developer myself but I understand that it would take a mammoth effort to modify FG's core to better support multi-cores and other resources effectively.<br/> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=153262}} | ||
|title=<nowiki>[SUGGESTION] Multi-core FlightGear support</nowiki> | |title=<nowiki>[SUGGESTION] Multi-core FlightGear support</nowiki> | ||
|author=<nowiki>Vinura</nowiki> | |author=<nowiki>Vinura</nowiki> | ||
Line 379: | Line 379: | ||
<br/> | <br/> | ||
So your CPUs and idle cores are still relevant to handle all non-rendering related jobs, and other computations that are not appropriate for the GPU (ATM). Things like AI traffic, the FDM, autopilot computations, Nasal code - these all run in the main loop, before the final frame is created and rendered. So depending on how long each step takes, frame rate/spacing may fluctuate - which is less likely to show up on really fast systems like Thorsten reported. | So your CPUs and idle cores are still relevant to handle all non-rendering related jobs, and other computations that are not appropriate for the GPU (ATM). Things like AI traffic, the FDM, autopilot computations, Nasal code - these all run in the main loop, before the final frame is created and rendered. So depending on how long each step takes, frame rate/spacing may fluctuate - which is less likely to show up on really fast systems like Thorsten reported. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=181613}} | ||
|title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 388: | Line 388: | ||
{{FGCquote | {{FGCquote | ||
|the idea is not to use idle CPU cores for rendering related stuff - but rather optimize the FG<->OSG pipeline such that more main loop resources become available, so that certain tasks can be offloaded onto other cores. For example, OSG is able to run certain rendering-related optimizations asynchronously, outside the main loop. But that requires a paradigm change, because of the way FG makes currently use of OSG in a fairly sub-optimal fashion, even though Thorsten is right in saying that this particular issue doesn't show up on extremely fast systems with high-speed CPUs. | |the idea is not to use idle CPU cores for rendering related stuff - but rather optimize the FG<->OSG pipeline such that more main loop resources become available, so that certain tasks can be offloaded onto other cores. For example, OSG is able to run certain rendering-related optimizations asynchronously, outside the main loop. But that requires a paradigm change, because of the way FG makes currently use of OSG in a fairly sub-optimal fashion, even though Thorsten is right in saying that this particular issue doesn't show up on extremely fast systems with high-speed CPUs. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=181613}} | ||
|title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 398: | Line 398: | ||
<br/> | <br/> | ||
At the moment, we simply have unused optimization potential because of the way FG uses OSG/OpenGL, i.e. not following the proper coding patterns. | At the moment, we simply have unused optimization potential because of the way FG uses OSG/OpenGL, i.e. not following the proper coding patterns. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=181607}} | ||
|title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 407: | Line 407: | ||
{{FGCquote | {{FGCquote | ||
|I think HLA is a great idea for many reasons, because it addresses many unnecessary sources of bottlenecks. But I don't think it addresses all bottlenecks, in particular I don't think it addresses mine. Mathias has made it abundantly clear that he's not interested in high-end shader effects, but that he cares for multiple display setups and similar things. It's also become quite apparent to me that he doesn't really follow how our high-end effects actually are implemented and what they do. So my impression is that HLA will be a good thing for many purposes - when you're CPU limited for any reason, for MP, for multi-display setups,..., but I don't see how it will address situations where the bottleneck is shader code. | |I think HLA is a great idea for many reasons, because it addresses many unnecessary sources of bottlenecks. But I don't think it addresses all bottlenecks, in particular I don't think it addresses mine. Mathias has made it abundantly clear that he's not interested in high-end shader effects, but that he cares for multiple display setups and similar things. It's also become quite apparent to me that he doesn't really follow how our high-end effects actually are implemented and what they do. So my impression is that HLA will be a good thing for many purposes - when you're CPU limited for any reason, for MP, for multi-display setups,..., but I don't see how it will address situations where the bottleneck is shader code. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=181608}} | ||
|title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 418: | Line 418: | ||
{{FGCquote | {{FGCquote | ||
|From where I stand, we're mainly lacking willingness of users to actually run tests under guidance. If people can't be bothered to report their system specs or what they're actually doing in detail, then I can't see how they'd report more internal diagnostics. | |From where I stand, we're mainly lacking willingness of users to actually run tests under guidance. If people can't be bothered to report their system specs or what they're actually doing in detail, then I can't see how they'd report more internal diagnostics. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214050}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 427: | Line 427: | ||
{{FGCquote | {{FGCquote | ||
|many people don't even know how to get/deploy and use a nightly snapshot, let alone actually provide useful/actionable data, "useful" in the sense that developers can actually act upon that data | |many people don't even know how to get/deploy and use a nightly snapshot, let alone actually provide useful/actionable data, "useful" in the sense that developers can actually act upon that data | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214064}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 440: | Line 440: | ||
<br/> | <br/> | ||
So, rather than getting meaningful and actionable feedback from GIT users, we're seeing more and more non-actionable complaints that the version which is intended for testing and experiments isn't fully tested. | So, rather than getting meaningful and actionable feedback from GIT users, we're seeing more and more non-actionable complaints that the version which is intended for testing and experiments isn't fully tested. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214050}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 450: | Line 450: | ||
|I don't know - personally, I believe we simply couldn't deal with the results: Just look at some of the recent developments in this area, such as the integrated "Crash Reporting" system: We've been seeing dozens of users making extensive use of this - and then it became obvious that the SINGLE recipient of all these bug reports simply couldn't deal with the sheer number of reports, because we never established any mechanism to process all the feedback at a larger scale. Or look at the issue tracker and the number of "critical" bugs there - which I think kinda proves the point that we, as a project, cannot deal with too much feedback. Even though that may not necessarily apply to other contributors, like yourself. But the few people who do not just have 2-3 "pet projects", but who maintain the whole simulator, cannot deal with the sheer amoung of feedback.<br/> | |I don't know - personally, I believe we simply couldn't deal with the results: Just look at some of the recent developments in this area, such as the integrated "Crash Reporting" system: We've been seeing dozens of users making extensive use of this - and then it became obvious that the SINGLE recipient of all these bug reports simply couldn't deal with the sheer number of reports, because we never established any mechanism to process all the feedback at a larger scale. Or look at the issue tracker and the number of "critical" bugs there - which I think kinda proves the point that we, as a project, cannot deal with too much feedback. Even though that may not necessarily apply to other contributors, like yourself. But the few people who do not just have 2-3 "pet projects", but who maintain the whole simulator, cannot deal with the sheer amoung of feedback.<br/> | ||
Thus, I think that built-in diagnostics and automated regression testing would help us more in the long term, i.e. kinda like the whole "benchmark" debate we've been seeing for years. The final result could then be a "flight recorder tape" that includes important run-time info, i.e. stats but also log files. | Thus, I think that built-in diagnostics and automated regression testing would help us more in the long term, i.e. kinda like the whole "benchmark" debate we've been seeing for years. The final result could then be a "flight recorder tape" that includes important run-time info, i.e. stats but also log files. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214064}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 465: | Line 465: | ||
<br/> | <br/> | ||
It is simply ''not'' true that such things go unnoticed. I made a report about 2.0 scenery resource consumption to the devel list prior to the 3.0 release. There have been many discussions on memory consumption. | It is simply ''not'' true that such things go unnoticed. I made a report about 2.0 scenery resource consumption to the devel list prior to the 3.0 release. There have been many discussions on memory consumption. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214050}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 475: | Line 475: | ||
{{FGCquote | {{FGCquote | ||
|I'm not a developer so, please, don't expect me to give the detail you want. I'm an end user, that's all. What I know is that there ***IS*** something wrong with FG because it's getting slow over time. What I do know is that a plane with a level of detail of the 777-S should NOT eat that much ram. What I do know is that there are other simulator which renders a lot more scenery than FG and yet they don't eat too much RAM. What I do know is that sims like FSX will make the scenery as low detail as possible when you get far from it. Hell, if you're 500m from a mountain it'll start to get such low polygon count it'll actually look like a 90's game. Does it matter? No, because probably most people don't pay much attention to what's far. | |I'm not a developer so, please, don't expect me to give the detail you want. I'm an end user, that's all. What I know is that there ***IS*** something wrong with FG because it's getting slow over time. What I do know is that a plane with a level of detail of the 777-S should NOT eat that much ram. What I do know is that there are other simulator which renders a lot more scenery than FG and yet they don't eat too much RAM. What I do know is that sims like FSX will make the scenery as low detail as possible when you get far from it. Hell, if you're 500m from a mountain it'll start to get such low polygon count it'll actually look like a 90's game. Does it matter? No, because probably most people don't pay much attention to what's far. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214062}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>junior-s</nowiki> | |author=<nowiki>junior-s</nowiki> | ||
Line 485: | Line 485: | ||
{{FGCquote | {{FGCquote | ||
|In cases of flightgear being heavy on resources, i have often seen comments like: "lower the settings". Often and surely temporarily that can be a valid solution. But in some cases i think: do not leave it at that statement, because surely a smart solution can be found. | |In cases of flightgear being heavy on resources, i have often seen comments like: "lower the settings". Often and surely temporarily that can be a valid solution. But in some cases i think: do not leave it at that statement, because surely a smart solution can be found. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214004}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>KL-666</nowiki> | |author=<nowiki>KL-666</nowiki> | ||
Line 495: | Line 495: | ||
{{FGCquote | {{FGCquote | ||
|Moreover, I've always been in favour of trying to clearly propose the user a low-end and a high-end version of FG, evolving with the ongoing versions. And I mean clearly, not by having to spend time understanding sliders | |Moreover, I've always been in favour of trying to clearly propose the user a low-end and a high-end version of FG, evolving with the ongoing versions. And I mean clearly, not by having to spend time understanding sliders | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214283}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>f-ojac</nowiki> | |author=<nowiki>f-ojac</nowiki> | ||
Line 506: | Line 506: | ||
<br/> | <br/> | ||
However, what could work is making more and more FlightGear default settings and subsystems entirely optional, so that FlightGear becomes increasingly run-time configurable - which would allow the same fgfs binary to be used for hugely different purposes. Zakalawe has been working on this as part of better run-time re-initialization, where fgcommands/Nasal APIs can be used to dynamically disable and enable whole subsystems, which are then "booted" (or shut-down) on demand. This works already for roughly a dozen of subsystems, but the real resource hogs are not yet optional. | However, what could work is making more and more FlightGear default settings and subsystems entirely optional, so that FlightGear becomes increasingly run-time configurable - which would allow the same fgfs binary to be used for hugely different purposes. Zakalawe has been working on this as part of better run-time re-initialization, where fgcommands/Nasal APIs can be used to dynamically disable and enable whole subsystems, which are then "booted" (or shut-down) on demand. This works already for roughly a dozen of subsystems, but the real resource hogs are not yet optional. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214286}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 514: | Line 514: | ||
{{FGCquote | {{FGCquote | ||
|I don't quite see how we could come up with different versions, binaries and packages of FG easily - but we could certainly prepare the main binary to become increasingly configurable, so that it can be used for such purposes - it would even be possible to use built-in FG dialogs in an external window, running in a standalone process - e.g. for an instructor console, but also for a Canvas-driven TerraGear GUI. | |I don't quite see how we could come up with different versions, binaries and packages of FG easily - but we could certainly prepare the main binary to become increasingly configurable, so that it can be used for such purposes - it would even be possible to use built-in FG dialogs in an external window, running in a standalone process - e.g. for an instructor console, but also for a Canvas-driven TerraGear GUI. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214286}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 524: | Line 524: | ||
|I looked at the "FGCanvas" branch I started last year to see how many subsystems can be easily made optional these days. Primarily with a focus on aircraft & scenery subsystems - the idea is to put those into dedicated subsystem groups, so that resource utilization can be OPTIONALLY tracked per group. This would make it possible to overload operator new at the SGSubsystem/Group-level to track most allocations and provide /some/ stats.<br/> | |I looked at the "FGCanvas" branch I started last year to see how many subsystems can be easily made optional these days. Primarily with a focus on aircraft & scenery subsystems - the idea is to put those into dedicated subsystem groups, so that resource utilization can be OPTIONALLY tracked per group. This would make it possible to overload operator new at the SGSubsystem/Group-level to track most allocations and provide /some/ stats.<br/> | ||
<br/> | <br/> | ||
And the results are pretty encouraging actually: | And the results are pretty encouraging actually: {{forum link|p=214262|text=Subject: FGCanvas Experiments & Updates}} | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214286}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 534: | Line 534: | ||
{{FGCquote | {{FGCquote | ||
| I don't think it's fair to all "blame" it all on more TerraGear progress - the underlying issue is a known one, and we've seen recurring patterns here long before World Scenery 2.0, it's just the concrete manifestation that differs over time, but otherwise the culprit is that we 1) don't provide any optional diagnostics to tell what's going on in terms of CPU/GPU/RAM/VRAM utilization, and 2) that we don't do any headless regression testing when adding new features. So I can kinda relate to people feeling "locked out". We're certainly far from being user-friendly, if people have to be around for half a decade to turn FG into a usable piece of software | | I don't think it's fair to all "blame" it all on more TerraGear progress - the underlying issue is a known one, and we've seen recurring patterns here long before World Scenery 2.0, it's just the concrete manifestation that differs over time, but otherwise the culprit is that we 1) don't provide any optional diagnostics to tell what's going on in terms of CPU/GPU/RAM/VRAM utilization, and 2) that we don't do any headless regression testing when adding new features. So I can kinda relate to people feeling "locked out". We're certainly far from being user-friendly, if people have to be around for half a decade to turn FG into a usable piece of software | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213986}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 543: | Line 543: | ||
{{FGCquote | {{FGCquote | ||
| I also find it more "exciting" to do some fancy Canvas display than fixing the Nasal/GC - and that seems to apply to roughly half a dozen of people around here who obviously have the mental capacity and expertise to address such issues, no matter if it's an alternate Nasal/GC scheme, or an improved threading architecture - still, we're all motivated by things having to be fun, and there's really only a single guy who seems to "enjoy" doing the unglamorous work of fixing other people's ugly code all over the place, and that guy is kinda busy with allowing aircraft to be switched at run-time | | I also find it more "exciting" to do some fancy Canvas display than fixing the Nasal/GC - and that seems to apply to roughly half a dozen of people around here who obviously have the mental capacity and expertise to address such issues, no matter if it's an alternate Nasal/GC scheme, or an improved threading architecture - still, we're all motivated by things having to be fun, and there's really only a single guy who seems to "enjoy" doing the unglamorous work of fixing other people's ugly code all over the place, and that guy is kinda busy with allowing aircraft to be switched at run-time | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213986}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 552: | Line 552: | ||
{{FGCquote | {{FGCquote | ||
|that's basically a matter of providing some kind of dedicated monitoring function, analogous to the existing system monitor, which also tracks other resources, such as RAM/VRAM - at least optionally. | |that's basically a matter of providing some kind of dedicated monitoring function, analogous to the existing system monitor, which also tracks other resources, such as RAM/VRAM - at least optionally. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213986}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 563: | Line 563: | ||
Obviously someone familiar with Nasal, GLSL and C++ doesn't need such tools, but these people can usually also provide good bug reports without any hand-holding. But the instant we expect our end-users to make useful bug reports, we need to integrate and provide optional diagnostics - analogous to the system/performance monitor or the OSG on-screen stats, otherwise we'll keep on having these discussions for another 5+ years probably. <br/> | Obviously someone familiar with Nasal, GLSL and C++ doesn't need such tools, but these people can usually also provide good bug reports without any hand-holding. But the instant we expect our end-users to make useful bug reports, we need to integrate and provide optional diagnostics - analogous to the system/performance monitor or the OSG on-screen stats, otherwise we'll keep on having these discussions for another 5+ years probably. <br/> | ||
To be honest, I find your whole point about "not needing a debugger/profiler" kinda moot actually - you are without doubt referring to your own work here, which you're highly familiar with. Then again, I am sure that our degree of improving performance issues in FG would be much better if we had access to such tools, because it would no longer necessarily involve all the manual work, and we'd be much more likely to look at areas that we didn't write ourselves originally. I've really only seen 2-3 guys around here who regularly roll up their sleeves and try to "debug" Nasal-induced performance issues reported by end-users. And even core developers keep emphasizing how the lack of a debugger is making Nasal less appealing | To be honest, I find your whole point about "not needing a debugger/profiler" kinda moot actually - you are without doubt referring to your own work here, which you're highly familiar with. Then again, I am sure that our degree of improving performance issues in FG would be much better if we had access to such tools, because it would no longer necessarily involve all the manual work, and we'd be much more likely to look at areas that we didn't write ourselves originally. I've really only seen 2-3 guys around here who regularly roll up their sleeves and try to "debug" Nasal-induced performance issues reported by end-users. And even core developers keep emphasizing how the lack of a debugger is making Nasal less appealing | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214064}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 573: | Line 573: | ||
|I am not interested in providing end-user support, or in dealing with poor bug reports, I am interested in providing people with means to provide us with good information that we can act upon, and I don't want this to be specific about a single technology, let alone a single subsystem like AW/ALS etc, or even require the people who originally wrote the code to be around to make sense of an issue. But I never said anywhere that I wanted to integrate a profiler or debugger necessarily - those are fairly low-level tools and most end-users couldn't deal with them either. <br/> | |I am not interested in providing end-user support, or in dealing with poor bug reports, I am interested in providing people with means to provide us with good information that we can act upon, and I don't want this to be specific about a single technology, let alone a single subsystem like AW/ALS etc, or even require the people who originally wrote the code to be around to make sense of an issue. But I never said anywhere that I wanted to integrate a profiler or debugger necessarily - those are fairly low-level tools and most end-users couldn't deal with them either. <br/> | ||
In fact, there's an integrated profiler, which while optional, is being used by fellow coders - and I was the one who provided the corresponding patch. Yet, I fully realize that is has not much of a merit when it comes to dealing with end-users. | In fact, there's an integrated profiler, which while optional, is being used by fellow coders - and I was the one who provided the corresponding patch. Yet, I fully realize that is has not much of a merit when it comes to dealing with end-users. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214076}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 584: | Line 584: | ||
<br/> | <br/> | ||
I do think that my whole point about troubleshooting code that we also didn't write originally still holds true - I've worked with code like AW and Bombable, and quite a few other non-trivial scripts/applications, and here, having OPTIONAL tools to help diagnose issues (CPU/RAM utilization) is the most essential time-saver, and basically the motivator and key-prerequisite to actually consider such attempts. | I do think that my whole point about troubleshooting code that we also didn't write originally still holds true - I've worked with code like AW and Bombable, and quite a few other non-trivial scripts/applications, and here, having OPTIONAL tools to help diagnose issues (CPU/RAM utilization) is the most essential time-saver, and basically the motivator and key-prerequisite to actually consider such attempts. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214076}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 598: | Line 598: | ||
Another option more resources, almos 4 GB RAM, etc.<br/> | Another option more resources, almos 4 GB RAM, etc.<br/> | ||
And finally the moster option for i7 more than 8 GB all render options on, etc | And finally the moster option for i7 more than 8 GB all render options on, etc | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214287}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Prometeo 2013</nowiki> | |author=<nowiki>Prometeo 2013</nowiki> | ||
Line 608: | Line 608: | ||
| the main challenge is that FlightGear was never designed to do any form of explicit memory management, as per Stuart's comments here:<br/> | | the main challenge is that FlightGear was never designed to do any form of explicit memory management, as per Stuart's comments here:<br/> | ||
<br/> | <br/> | ||
{{forum link|p=165125|text=Subject: Random Buildings}}<br/> | |||
{{cquote|I think it also opens up a larger question of how we do memory management in FG, and whether we should be doing things such as more aggressively freeing up terrain tiles. At one level, removing entire terrain tiles from memory earlier if memory occupancy becomes a concern would be a better management strategy than just stopping generating new buildings.<br/> | {{cquote|I think it also opens up a larger question of how we do memory management in FG, and whether we should be doing things such as more aggressively freeing up terrain tiles. At one level, removing entire terrain tiles from memory earlier if memory occupancy becomes a concern would be a better management strategy than just stopping generating new buildings.<br/> | ||
<br/> | <br/> | ||
-Stuart}} | -Stuart}} | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214289}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 623: | Line 623: | ||
<br/> | <br/> | ||
It's not something that can be simply suggested, the code needs to know 1) how much it is using (which needs to be implemented for each supported platform), 2) where/how it is using it (specific subsystems), and 3) how to deal with situations like "not enough memory" vs. "sufficient memory: give me more features" - some data structures can be safely freed, while others would be critical for the simulator to work properly. | It's not something that can be simply suggested, the code needs to know 1) how much it is using (which needs to be implemented for each supported platform), 2) where/how it is using it (specific subsystems), and 3) how to deal with situations like "not enough memory" vs. "sufficient memory: give me more features" - some data structures can be safely freed, while others would be critical for the simulator to work properly. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214289}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 632: | Line 632: | ||
=== OpenCL Support === | === OpenCL Support === | ||
{{FGCquote | {{FGCquote | ||
|Also, eventually adopting | |Also, eventually adopting {{forum link|hilit=opencl|p=140065|text=OpenCL support}} would be a great way for some projects like local weather to parallelize more and more code.<br/> | ||
<br/> | <br/> | ||
Thorsten mentioned | Thorsten mentioned {{forum link|p=93223|text=quite a while ago}}, that the local weather system has some code that would be trivially parallelizable:<br/> | ||
<br/> | <br/> | ||
{{cquote|Most weather tasks parallelize almost trivially:<br/> | {{cquote|Most weather tasks parallelize almost trivially:<br/> | ||
Line 643: | Line 643: | ||
<br/> | <br/> | ||
and so on - the main question is if the interaction with the Flightgear core (i.e. terrain info calls or writing into the property tree) can be structured such that parallel computation is useful.}} | and so on - the main question is if the interaction with the Flightgear core (i.e. terrain info calls or writing into the property tree) can be structured such that parallel computation is useful.}} | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=144679}} | ||
|title=<nowiki>Re: A local weather system (v1.36 available)</nowiki> | |title=<nowiki>Re: A local weather system (v1.36 available)</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 663: | Line 663: | ||
<br/> | <br/> | ||
Obviously, that would require some thinking, because the Nasal code running asynchronously could no longer directly instantiate scenery objects (clouds etc), but would instead have to make a "network call" to the Nasal interpreter running inside the FG process instead. But I am pretty confident that this could eventually be solved by a workaround like the compat layer, i.e. by using a wrapper layer that redirects commands accordingly. | Obviously, that would require some thinking, because the Nasal code running asynchronously could no longer directly instantiate scenery objects (clouds etc), but would instead have to make a "network call" to the Nasal interpreter running inside the FG process instead. But I am pretty confident that this could eventually be solved by a workaround like the compat layer, i.e. by using a wrapper layer that redirects commands accordingly. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=146518}} | ||
|title=<nowiki>Re: A local weather system (v1.4 available)</nowiki> | |title=<nowiki>Re: A local weather system (v1.4 available)</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 674: | Line 674: | ||
{{FGCquote | {{FGCquote | ||
|This isn't the first person/contributor to state pretty clearly that they're kinda disappointed with the way FG has evolved over the years, some others stated pretty clearly that even a recent version of X-Plane looks and works better than FG 3.x using the same hardware - so I guess we should take this for what it is, i.e. feedback demonstrating that people no longer know how to scale down FlightGear's features. Admittedly, I also find myself having to do quite a bit of tweaking these days, despite having fairly powerful hardware. Stating that all these are optional features and that people "merely" need to disable those, is as short-sighted as the whole multi-threading debate that we've been having since ~2006 ... Obviously, the "minimal startup profile" should still work for people, and it should easily provide ~60 fps, but that's not what people want FG to look like, and there are other products that simply provide a better experience. | |This isn't the first person/contributor to state pretty clearly that they're kinda disappointed with the way FG has evolved over the years, some others stated pretty clearly that even a recent version of X-Plane looks and works better than FG 3.x using the same hardware - so I guess we should take this for what it is, i.e. feedback demonstrating that people no longer know how to scale down FlightGear's features. Admittedly, I also find myself having to do quite a bit of tweaking these days, despite having fairly powerful hardware. Stating that all these are optional features and that people "merely" need to disable those, is as short-sighted as the whole multi-threading debate that we've been having since ~2006 ... Obviously, the "minimal startup profile" should still work for people, and it should easily provide ~60 fps, but that's not what people want FG to look like, and there are other products that simply provide a better experience. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213974}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 684: | Line 684: | ||
|So, I'd say we do have a problem, but what people consider the problem is usually just a symptom and not the real culprit. <br/> | |So, I'd say we do have a problem, but what people consider the problem is usually just a symptom and not the real culprit. <br/> | ||
But that should be understandable, most non-coders cannot easily understand all the factors involved here. | But that should be understandable, most non-coders cannot easily understand all the factors involved here. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213974}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 696: | Line 696: | ||
If you know about any way to obtain this kind of low-level information without using the tools that you refuse to use, I'd be intrigued to learn more. <br/> | If you know about any way to obtain this kind of low-level information without using the tools that you refuse to use, I'd be intrigued to learn more. <br/> | ||
But ´for now, we're obviously talking about hugely different things, and one of us refuses to accept that end-users may have a point, even without having to be familiar with FG internals and all the lingo involved. | But ´for now, we're obviously talking about hugely different things, and one of us refuses to accept that end-users may have a point, even without having to be familiar with FG internals and all the lingo involved. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214111}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 707: | Line 707: | ||
<br/> | <br/> | ||
Again, I never said that any of those had to be integrated - I just said, that /we/ may have to use them at times, and that we should probably strive to OPTIONALLY provide certain diagnostics at run-time to enable end-users to provide us with better information/bug reports. It's the difference between having a systime() API in Nasal, and not having one: 99% of our users may never use it, but people like you, may use it to tell what's going on. | Again, I never said that any of those had to be integrated - I just said, that /we/ may have to use them at times, and that we should probably strive to OPTIONALLY provide certain diagnostics at run-time to enable end-users to provide us with better information/bug reports. It's the difference between having a systime() API in Nasal, and not having one: 99% of our users may never use it, but people like you, may use it to tell what's going on. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214111}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 716: | Line 716: | ||
{{FGCquote | {{FGCquote | ||
|I never even questioned that our current issue is scenery related, I just said that we've been seeing other issues, and I pointed out that a few of us provided patches to recognize such issues much earlier (the v2.0 scenery issue was RANDOMLY identified by Atlas core developer Brian Schack if you remember). Had we integrated the corresponding resource tracking patches that we discussed (and posted) 4+ years ago, we would have had a much better chance of detecting such issues - even regardless of them being specific to scenery, the Nasal GC or whatever. | |I never even questioned that our current issue is scenery related, I just said that we've been seeing other issues, and I pointed out that a few of us provided patches to recognize such issues much earlier (the v2.0 scenery issue was RANDOMLY identified by Atlas core developer Brian Schack if you remember). Had we integrated the corresponding resource tracking patches that we discussed (and posted) 4+ years ago, we would have had a much better chance of detecting such issues - even regardless of them being specific to scenery, the Nasal GC or whatever. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214196}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 726: | Line 726: | ||
{{FGCquote | {{FGCquote | ||
|All it takes to run the recent FG version on old hardware is to not use optional features and dial down the configuration. The project is most definitely not going into any direction making it impossible for some people to use FG - there's huge concern over backward compatibility on the devel list. | |All it takes to run the recent FG version on old hardware is to not use optional features and dial down the configuration. The project is most definitely not going into any direction making it impossible for some people to use FG - there's huge concern over backward compatibility on the devel list. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213960}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 737: | Line 737: | ||
<br/> | <br/> | ||
Maxing out all options together (most detailed aircraft, most detailed scenery, high graphic detail,...) is intended for people with gaming hardware. Asking to be able to run that on every bit of hardware is unreasonable. | Maxing out all options together (most detailed aircraft, most detailed scenery, high graphic detail,...) is intended for people with gaming hardware. Asking to be able to run that on every bit of hardware is unreasonable. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213972}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>Thorsten</nowiki> | |author=<nowiki>Thorsten</nowiki> | ||
Line 746: | Line 746: | ||
{{FGCquote | {{FGCquote | ||
|I agree wrt to valgrind, specifically if you want to profile, use callgrind and see in pretty colours how much time a piece of code takes to run. Requires lots of patience though. | |I agree wrt to valgrind, specifically if you want to profile, use callgrind and see in pretty colours how much time a piece of code takes to run. Requires lots of patience though. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214112}} | ||
|title=<nowiki>Re: How can I retire from the forum?</nowiki> | |title=<nowiki>Re: How can I retire from the forum?</nowiki> | ||
|author=<nowiki>adrian</nowiki> | |author=<nowiki>adrian</nowiki> |
Latest revision as of 07:32, 11 June 2019
Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments. |
Background
Symptoms
Why do I have frame-rates of 8 - 60 sometimes, depending (mostly) on local weather and all settings to maxx. And here comes the part I mean to talk about: Why does my GPU jumps to 70°C in a minute or so, while my 2CPUs run gently with 50% usage each. (threading : auto)
— chris_blues (Thu Apr 18). Can FG computations be made more balanced?.
(powered by Instant-Cquotes) |
v2.0 Scenery
The numbers say that without any doubt, 2.0 scenery is what uses all the memory, nothing else - not hires textures, not trees.
|
Memory Footprint
CPU vs. GPU work
If you have a halfway decent GPU, when you ask a rendering task (texture lookups, vector transformations, matrix multiplications,...) , the additional performance of 8 CPUs is pretty negligible. The GPU does these tasks in lightning speed.
— Thorsten (Fri Apr 19). Re: Can FG computations be made more balanced?.
(powered by Instant-Cquotes) |
on a high-end GPU (which I assume you have), the single determining factor for the framerate seems to be the vertex count of clouds, buildings and trees (in this order). So rendering overcast sky makes a huge difference to rendering clear sky, rendering a city worth of random buildings makes a huge difference to rendering a desert, and rendering dense forests makes a difference to rendering a few patches of green. With all details to max, we probably burn 99% of the total computational load in rendering (it's about 1200 lines of instructions per pixel 30-60 times per second), all other flight related tasks like computing aerodynamics are small in comparison.
— Thorsten (Fri Apr 19). Re: Can FG computations be made more balanced?.
(powered by Instant-Cquotes) |
the only thing that I can identify as affecting my framerate is the vertex pipeline. Currently, with the rest I can pretty much do what I like. The Concorde with it's gazillions of systems runs as fast as a glider. The high-fideltity (or at least quite complex FDM) T4T Spitfire runs as fast as any other plane. Switching background Nasal on and off makes no bloody difference for anything. Only what enters the vertex pipeline does. Or lots and lots of semi-transparent stacks in the fragment pipeline - they can eventually kill as well.
— Thorsten (Fri Apr 19). Re: Can FG computations be made more balanced?.
(powered by Instant-Cquotes) |
The vast majority of the computing load is generated due to rendering, i.e. if you have GPU support (as with any modern graphics card) it doesn't touch the CPU at all. The framerate is usually determined exclusively by the GPU capability - distributing CPU load across several cores may be elegant conceptually, but doesn't make anything run faster.
— Thorsten (Thu Mar 15). Re: [SUGGESTION] Multi-core FlightGear support.
(powered by Instant-Cquotes) |
Our Main Loop & HLA
I think HLA is a great idea for many reasons, because it addresses many unnecessary sources of bottlenecks. But I don't think it addresses all bottlenecks, in particular I don't think it addresses mine. Mathias has made it abundantly clear that he's not interested in high-end shader effects, but that he cares for multiple display setups and similar things. It's also become quite apparent to me that he doesn't really follow how our high-end effects actually are implemented and what they do. So my impression is that HLA will be a good thing for many purposes - when you're CPU limited for any reason, for MP, for multi-display setups,..., but I don't see how it will address situations where the bottleneck is shader code.
— Thorsten (Fri Apr 19). Re: Can FG computations be made more balanced?.
(powered by Instant-Cquotes) |
About Testing
Lack of Feedback from End Users
many people don't even know how to get/deploy and use a nightly snapshot, let alone actually provide useful/actionable data, "useful" in the sense that developers can actually act upon that data
|
Poor Quality of Bug Reports
Proposals
FlightGear light ?
I looked at the "FGCanvas" branch I started last year to see how many subsystems can be easily made optional these days. Primarily with a focus on aircraft & scenery subsystems - the idea is to put those into dedicated subsystem groups, so that resource utilization can be OPTIONALLY tracked per group. This would make it possible to overload operator new at the SGSubsystem/Group-level to track most allocations and provide /some/ stats.
|
Resource Utilization Tracking
that's basically a matter of providing some kind of dedicated monitoring function, analogous to the existing system monitor, which also tracks other resources, such as RAM/VRAM - at least optionally.
|
Feature Scaling
Thus, while the idea to scale features up/down, depending on available resources, the majority of the legacy code in FG (especially anything unrelated to OSG/rendering) would need to be explicitly re-architected to 1) track memory allocations & freeing, and to also adjust subsystems and their features accordingly.
|
OpenCL Support
Also, eventually adopting OpenCL support would be a great way for some projects like local weather to parallelize more and more code.
|
Moving some Nasal code to other cores
some people have repeatedly expressed an interest in eventually running a weather simulation asynchronously from the main loop, i.e. either multi-threaded or in a separate process (the HLA interface was mentioned by Mathias and Torsten).
|
Feature Scaling
This isn't the first person/contributor to state pretty clearly that they're kinda disappointed with the way FG has evolved over the years, some others stated pretty clearly that even a recent version of X-Plane looks and works better than FG 3.x using the same hardware - so I guess we should take this for what it is, i.e. feedback demonstrating that people no longer know how to scale down FlightGear's features. Admittedly, I also find myself having to do quite a bit of tweaking these days, despite having fairly powerful hardware. Stating that all these are optional features and that people "merely" need to disable those, is as short-sighted as the whole multi-threading debate that we've been having since ~2006 ... Obviously, the "minimal startup profile" should still work for people, and it should easily provide ~60 fps, but that's not what people want FG to look like, and there are other products that simply provide a better experience.
|
So, I'd say we do have a problem, but what people consider the problem is usually just a symptom and not the real culprit. But that should be understandable, most non-coders cannot easily understand all the factors involved here. |
To see for yourself, start up in a place without any scenery, keep FG running for several hours and then see the valgrind report (one of those tools that you refuse to use), while it's true that valgrind outupt is misleading in the context of OSG's ref_ptr's (smart pointers, that manage memory), we do have a number of memory-leaking features, including particles and even effects.
|
Things like a slow Nasal/GC scheme are those that you cannot easily track down, without using tools like a profiler, debugger or leaks checking tool.
|
I never even questioned that our current issue is scenery related, I just said that we've been seeing other issues, and I pointed out that a few of us provided patches to recognize such issues much earlier (the v2.0 scenery issue was RANDOMLY identified by Atlas core developer Brian Schack if you remember). Had we integrated the corresponding resource tracking patches that we discussed (and posted) 4+ years ago, we would have had a much better chance of detecting such issues - even regardless of them being specific to scenery, the Nasal GC or whatever.
|
Optional Features
All it takes to run the recent FG version on old hardware is to not use optional features and dial down the configuration. The project is most definitely not going into any direction making it impossible for some people to use FG - there's huge concern over backward compatibility on the devel list.
|
I mean, in that context FG is just a platform which runs the data you throw at it. Someone decided to develop that 777-S at high detail, and then it consumes more memory. Should the devel team veto detailed aircraft based on the notion that they might not run on all systems? Or could we perhaps trust users to select aircraft based on what runs on their system and what they want to have?
|
I agree wrt to valgrind, specifically if you want to profile, use callgrind and see in pretty colours how much time a piece of code takes to run. Requires lots of patience though.
|