[Flightgear-devel] Speed problems under Solaris
Hello. Someone said that it is no problem to run FlightGear even on an Ultra-5 machine. I run FlightGear on a Blade 1000 with an 750 MHz UltraSparc processor (this is equal to a Pentium machine with 2,3 or 3 GHz speed). The screen refreshes every 8 seconds. Any keyboard input requires 8 seconds until FlightGear processes the keyboard input. My Windows machine has 2 GHz of speed and the time is less than one second. The top tool says that 96% of the processor time is used by fgfs and only 1% by Xsun. This shows me that 3D graphics is not the problem because the 3D graphics is done by the X server (Xsun - or more exactly by the 3D graphics accelerator card). I thought that sound would be the problem but --disable-sound will not enhance the speed. Another problem is that there is no text in the menu but only some random graphics. Any ideas ? I need help with that. Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Martin Rosenau wrote: Someone said that it is no problem to run FlightGear even on an Ultra-5 machine. This could have been my statement, but in this form it is incomplete. I _do_ expect that the CPU of an Ultra5 is sufficient for running FlightGear _but_ you have to have an appropriate graphics board. I'd expect that you need something in the XVR-1000 range and I don't know if that fits into an Ultra5. I run FlightGear on a Blade 1000 with an 750 MHz UltraSparc processor This should be capable of carrying a graphics board that qualifies. Which board do you currently use ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Speed problems under Solaris
I'd expect that you need something in the XVR-1000 range and I don't know if that fits into an Ultra5. Hello. I think it is not only a problem of graphics. Even the network stuff (e.g. props at TCP port 5501) has 8 seconds delay. This should be capable of carrying a graphics board that qualifies. Which board do you currently use ? I use an Elite-3D-m6 card. Thanks. Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Martin Rosenau wrote: I think it is not only a problem of graphics. Even the network stuff (e.g. props at TCP port 5501) has 8 seconds delay. I suspect the network stuff is coupled to the same loop as is the screen display. Just a guess, though I use an Elite-3D-m6 card. As far as I remember the Elite doesn't have any texture memory at all. Not having texture definitely memory kills FlightGear frame rates since the shading mode has been removed long time ago. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Martin Spott wrote: I suspect the network stuff is coupled to the same loop as is the screen display. Just a guess, though It is. Everything except for terrain tile I/O is driven out of the main loop. Probably something that should be fixed... Note that we're going to have to start thinking about threading designs soon anyway, if we want to take advantage of all the fancy multi-core/multi-thread CPUs coming down the pipe. Rendering obviously has to stay within a single thread, but how much non-rendering work can we push out to worker threads? Ideally, everything would be handed to the renderer thread each frame, with all the matrices pre-cooked and ready for OpenGL calls. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Andy Ross wrote: Martin Spott wrote: I suspect the network stuff is coupled to the same loop as is the screen display. Just a guess, though It is. Everything except for terrain tile I/O is driven out of the main loop. Probably something that should be fixed... Note that we're going to have to start thinking about threading designs soon anyway, if we want to take advantage of all the fancy multi-core/multi-thread CPUs coming down the pipe. Rendering obviously has to stay within a single thread, but how much non-rendering work can we push out to worker threads? Ideally, everything would be handed to the renderer thread each frame, with all the matrices pre-cooked and ready for OpenGL calls. I would like to make a case for non-threading from the standpoint of simplicity. We have had (and probably still have) some extremely subtle and extremely difficult to track bugs in our threaded tile loader. We've been forced to use threading for our tile loader simply because of performance reasons. We can't afford a big stutter in our animation when ever we need to load new tiles. When a single person is writing a smaller threaded app, things can work out quite well because one person (who understands all the underlying issues) can think through the code very carefully and ensure that all possible timing, locking, and communication related events are handled robustly. But now project that onto a project like FlightGear. Even if one highly skilled person set us up with lots of threading that worked perfectly, given all the contributions from a variety of sources (many of which I know have no clue about threading issues) how long do you think it will be before everything is hopelessly fouled up? Some simple naive change to fix some bug or add a new feature could inadvertantly introduce a subtle threading bug that only happens very rarely, but is still unacceptable. Personally, I think that the idea of threading in the context of FlightGear is a *very* scary idea, especially from the standpoint of long term maintanence and keeping our code robust. I'd perhaps favor splitting our code out into separate applications that use networking or shared memory or pipes to communicate. You lose some of the context switching efficiency of threads, but I think the code becomes more robust and maintanable because changes have less of a chance to propagate elsewhere to unintended areas ... Just my 2 cents ... :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Speed problems under Solaris
Hello. I found out that for each simulation step an usleep(93 ms) is done. The screen is updated only every 64 simulation steps. 93 ms X 64 = ~7 seconds I have no idea why the display is only updated ONLY every 64th simulation step. Textures are not the problem; I can use --disable-textures to get single-color triangles if textures are the problem. But I think that textures are no problem because - as far as I know - the texture stuff is done in the X server process which needs only few processor time. Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Martin Rosenau wrote: Hello. I found out that for each simulation step an usleep(93 ms) is done. The screen is updated only every 64 simulation steps. 93 ms X 64 = ~7 seconds I have no idea why the display is only updated ONLY every 64th simulation step. Textures are not the problem; I can use --disable-textures to get single-color triangles if textures are the problem. But I think that textures are no problem because - as far as I know - the texture stuff is done in the X server process which needs only few processor time. This *sounds* like you do not have opengl hardware acceleration on your machine. Even with textures off, FlightGear still uses opengl funtionality for it's depth buffer (hidden surface removal), fog, lighting, and transforming vertices from world coordinates to screen coordinates. All of this is really slow in software on a general purpose cpu which is why dedicated 3d hardware exists. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Curtis L. Olson wrote: Personally, I think that the idea of threading in the context of FlightGear is a *very* scary idea, especially from the standpoint of long term maintanence and keeping our code robust. I'd perhaps favor splitting our code out into separate applications that use networking or shared memory or pipes to communicate. I suspect more people would jump on this train if we manage to agree on the idea, that platform independent interfaces were a good thing (TM). We should 'hijack' this thread to start a discussion about wether it makes sense simply to take the current network interface protocols as given and write them down in some sort of an 'official' interface description. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
