On Mon, 09 Sep 2013 13:42:06 +0200, Erik wrote in message
522db40e.5050...@ehofman.com:
On 09/09/2013 12:59 PM, Renk Thorsten wrote:
A report of performance dramatically improving for advanced weather
when 3d clouds are switched off in the rendering menu (you still
get to see 3d clouds)
..another test case suggestion: if you have a radeon card, pop that
in and see how it looks with that, if you don't have a radeon card,
try swap out nvidea for nouveau in your /etc/X11/xorg.conf and
install your distro's nouveau and libdrm-nouveau2 etc drivers
alongside your nvidea drivers
On Tue, 10 Sep 2013 17:55:19 +, Renk wrote in message
e495a106ff5f31448739e79d34138c192a958...@mbs2.ad.jyu.fi:
..another test case suggestion: if you have a radeon card, pop that
in and see how it looks with that, if you don't have a radeon card,
try swap out nvidea for nouveau in your
A report of performance dramatically improving for advanced weather when 3d
clouds are switched off in the rendering menu (you still get to see 3d clouds)
http://www.flightgear.org/forums/viewtopic.php?f=69t=16630start=30#p189983
I've played around with this, and I can't reproduce any
On 09/09/2013 12:59 PM, Renk Thorsten wrote:
A report of performance dramatically improving for advanced weather when 3d
clouds are switched off in the rendering menu (you still get to see 3d clouds)
http://www.flightgear.org/forums/viewtopic.php?f=69t=16630start=30#p189983
I've played
Well, we did have
alpha-test
comparisongreater/comparison
reference type=float0.01/reference
/alpha-test
everywhere in the cloud effect files. So it's not clear to me how transparent
fragments should even make it to the shader (?). Maybe I'm still confused about
Hi everybody,
I just had the chance to compile a recent git-pull on my old and
battered linux-notebook workhorse and with great delight, I noticed that
I can run FlightGear again with 26fps at KSFO. I had to strip down most
eye candy shaders for the GeForce Go 7400 but 3D clouds render fine
Hi All,
While I hesitate to claim performance improvements I've not seen myself,
it may be that this was caused by this commit:
266b362238d0cef5a1c4df81bacbe941ee4c59ef
which discards transparent fragments. I'd be very interested if you could
revert the changes in that commit and let me know
Hi,
I noticed an ugly issue with many of our Nasal modules. Not sure if
that's a result of changed behaviour years ago, or it's just a common
copy paste issue that just wasn't noticed so far.
Problem is, lot's of Nasal modules listen to the property
/sim/signals/fdm-initialized
to
Op 26-11-10 18:12, fiers...@zonnet.nl schreef:
Hi All
Op 26-11-10 17:03, thorsten.i.r...@jyu.fi schreef:
Am I the only one?
No, you are not the only one. I made a similar observation a short while
ago and mailed that to this list. I also observed that the CPU loads
seem to be
Can you compare the OSG statistics between the two binaries? Choose
cycle onscreen statistics three times.
I sure can, but I have no idea what I am looking at when I do that - I
basically get a table with numbers which change when I move or change view
direction. I'd make screenshots
On Sat, Nov 27, 2010 at 2:33 PM, thorsten.i.r...@jyu.fi wrote:
Can you compare the OSG statistics between the two binaries? Choose
cycle onscreen statistics three times.
I sure can, but I have no idea what I am looking at when I do that - I
basically get a table with numbers which change
Take a screenshot with one of the system tools. I want to know which
traversal -- update, cull, draw, or gpu -- appears to be slower.
http://frbouvi.free.fr/flightsim/fgfs-20101108-KSFO-28R.png : from a nightly
build
http://frbouvi.free.fr/flightsim/fgfs-20101127-KSFO-28R.png : compiled
I've had just occasion to compare performance of a GIT binary compiled on
Nov 24th with a GIT binary compiled Nov 13th in one of my standard
benchmark tests (which I described a while ago), and the test confirmed an
impression I had yesterday in just test-flying - I've lost almost 1/3 of
available
Can you compare the OSG statistics between the two binaries? Choose cycle
onscreen statistics three times.
Tim
On Fri, Nov 26, 2010 at 5:03 PM, thorsten.i.r...@jyu.fi wrote:
I've had just occasion to compare performance of a GIT binary compiled on
Nov 24th with a GIT binary compiled Nov 13th
Hi All
Op 26-11-10 17:03, thorsten.i.r...@jyu.fi schreef:
Am I the only one?
No, you are not the only one. I made a similar observation a short while
ago and mailed that to this list. I also observed that the CPU loads
seem to be different. See also my message of 20 November, with
However, the (so far to me unknown) C++ subrouting actually bringing
clouds into the visibly rendered scenery is even way slower - I can read
the message that the property writing is over after the expected 2.5
seconds, but continue to see clouds appear in the scenery for 30 seconds
and more.
Not sure, maybe it is connected with an other issue we recently
discovered. There are indeed some OSG operations which don't scale
well.
For example, OSG keeps a simple list of references at each shared
model - so each shared model knows all nodes it is shared to. Adding a
new member to the
thorsten.i.r...@jyu.fi wrote:
However, the (so far to me unknown) C++ subrouting actually bringing
clouds into the visibly rendered scenery is even way slower - I can read
the message that the property writing is over after the expected 2.5
seconds, but continue to see clouds appear in the
Op 15-11-10 11:19, Martin Spott schreef:
This effect of 'asynchronously', 'delayed' loading of 3D models sounds
quite familiar to me and might reflect an intended feature in order to
save the framerate in these moments when a densely modelled chunk of
Scenery appears in the view.
Do 3D
With regard to the speed of loading models from Nasal into the scenery I
was writing about a while ago, I have made some discovery yesterday.
I was testing a setup in 2.0.0 with some heavy numerics running on the
second CPU, and this pushed the behaviour of the framerate into the
behaviour I was
From: thorsten.r...@jy... - 2010-11-12 10:13
I still have no real understanding why this is so, or why loading a large
number of *identical* models into the scenery should take a long time (I
would think that one can make use of the fact that there are really
multiple copies of the same model
Paris has been a heavy scenery for a long time, but in the
latest GIT it
seems as if it is becoming unusable. I am getting 9 or 10
FPS in
multithreading mode. A FGFS version of a couple of months
ago dropped my
FPS over Paris on the same system to about 12-15.
Performance seems to
have
Hi
Paris has been a heavy scenery for a long time, but in the latest GIT it
seems as if it is becoming unusable. I am getting 9 or 10 FPS in
multithreading mode. A FGFS version of a couple of months ago dropped my
FPS over Paris on the same system to about 12-15. Performance seems to
have
On Sun, Oct 24, 2010 at 12:53 PM, fiers...@zonnet.nl wrote:
A snapshot of the on screen statistics (in Debug) shows:
Update: 23.44
Call: 25 46
Draw: 33.40
GPU: 40.34
Call: 4.66
Draw: 1.96
GPU: 1.66
How should these numbers be interpretated? Are they percentages, like in
The GPU is
Hi,
Hi
Paris has been a heavy scenery for a long time, but in the
latest GIT it
seems as if it is becoming unusable. I am getting 9 or 10
FPS in
multithreading mode. A FGFS version of a couple of months
ago dropped my
FPS over Paris on the same system to about 12-15.
Performance
On Sunday 24 October 2010 05:02:23 Csaba Halász wrote:
On Sun, Oct 24, 2010 at 12:53 PM, fiers...@zonnet.nl wrote:
A snapshot of the on screen statistics (in Debug) shows:
Update: 23.44
Call: 25 46
Draw: 33.40
GPU: 40.34
Call: 4.66
Draw: 1.96
GPU: 1.66
How should these
On 10/2/2010 5:40 AM, thorsten.i.r...@jyu.fi wrote:
To follow up on my previous message:
Not so with my GIT binary: Loading of the initial cloud configuration
brings me down to 4 fps, and every time (!) a cloud is loaded from the
buffer my framerate drops from 34+ to something like 20+ for
Hello,
with significant help, I've recently succeeded to compile my own GIT
binary. Initially this was very slow, in the mean time I've been told some
flags for the compiler which I've been using to recompile OpenSceneGraph,
Simgear and Flightgear which improved the available framerate by a
Hi,
weekly resubmit. New this week:
o After scenery finishes loading:
FGScenery::getPagerSingleton()-setMaximumNumOfObjectsToCompilePerFrame(1);
Should help with excessive frame drops. Default is 4.
o Integrated James Turner's fixes, thank you.
o SGAtomic not longer used: big mem savings
Hi,
one little thing i was meaning to include but forgot. At the end of
fgMainLoop() add:
scenery_loaded = true;
}
if( ! scenery_loaded ) {
unsigned int tocompile =
FGScenery::getPagerSingleton()-getDataToCompileListSize();
unsigned int requests =
Hi,
On Thu, Dec 4, 2008 at 3:25 PM, Csaba Halász [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 3:58 AM, Yon Uriarte [EMAIL PROTECTED] wrote:
One big contributor to size is SGAtomic. On windows it's 32 bytes for a
4
byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes
Hi,
i was testing on my local airport (coastal, less terrain) with ufo, let me
test on inland airport (LEMD, madrid) with 172.
Im running with the patch that reduces precision for fgrunway, no longer can
we measure runway length in
super-cords widths, only upto 10 nanometers ;)
Memory (private
On 4 Dec 2008, at 02:58, Yon Uriarte wrote:thank you. I've keep working a bit on it. The airport ctor doesnt need to init the vectorxways>, it's wasteful.Well, see my version in that regard.Now it saves a few megabytes by removing unneeded parts from FGRunways (400k+ constructed) and using some
Hi,
On Thu, Dec 4, 2008 at 10:01 AM, James Turner [EMAIL PROTECTED] wrote:
On 4 Dec 2008, at 02:58, Yon Uriarte wrote:
thank you. I've keep working a bit on it. The airport ctor doesnt need to
init the vectorxways, it's wasteful.
Well, see my version in that regard.
I see, it's
On Thu, Dec 4, 2008 at 3:58 AM, Yon Uriarte [EMAIL PROTECTED] wrote:
One big contributor to size is SGAtomic. On windows it's 32 bytes for a 4
byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes payload.
After reading the docs on InterlockedIncrement (they say a 4 byte align
Hi,
thank you. I've keep working a bit on it. The airport ctor doesnt need to
init the vectorxways, it's wasteful.
Now it saves a few megabytes by removing unneeded parts from FGRunways
(400k+ constructed) and using some string instead of string copies.
By using those changes and also by using
Hi,
On Sun, Nov 30, 2008 at 12:56 AM, Tim Moore [EMAIL PROTECTED] wrote:
Yon Uriarte wrote:
Hi,
On Sat, Nov 29, 2008 at 1:41 AM, Tim Moore [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Yon Uriarte wrote:
Hi,
logstream.cxx:
Modified a bit the
On 1 Dec 2008, at 18:00, Yon Uriarte wrote:
I attach the patch for the airport, airway and navdb loaders. Also
included is the patch to throttle the frame rate while loading the
scenery at startup and to set the gzip input buffer to 64k (was 4k).
I believe all of them make sense and are
Hi
On Mon, Dec 1, 2008 at 7:20 PM, James Turner [EMAIL PROTECTED] wrote:
On 1 Dec 2008, at 18:00, Yon Uriarte wrote:
I attach the patch for the airport, airway and navdb loaders. Also
included is the patch to throttle the frame rate while loading the
scenery at startup and to set the
Hi,
On Mon, Dec 1, 2008 at 7:00 PM, Yon Uriarte [EMAIL PROTECTED] wrote:
I attach the patch for the airport, airway and navdb loaders. Also included
is the patch to throttle the frame rate while loading the scenery at startup
and to set the gzip input buffer to 64k (was 4k).
I believe all
Hi,
On Sat, Nov 29, 2008 at 1:41 AM, Tim Moore [EMAIL PROTECTED] wrote:
Yon Uriarte wrote:
Hi,
logstream.cxx:
Modified a bit the logstream implementation to avoid (stack) descent
down into (iostream) hell if we are not logging anything anyway. As it
is right now, it happily
Yon Uriarte wrote:
Hi,
On Sat, Nov 29, 2008 at 1:41 AM, Tim Moore [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Yon Uriarte wrote:
Hi,
logstream.cxx:
Modified a bit the logstream implementation to avoid (stack)
descent
down into (iostream)
Hi,
it seems this message was deleted (over 40k). I cant find it on the
archives so im resending it now with a compressed patch. Please ignore if
this is a repost.
--
this patch tries to speed up airways laoding. The strutils funcions are
Hi,
took a quick stab at navaid parsing. Also, i modified strutils::do_strip to
avoid calling string::operator[] excessively. Results:
Airport load time: 1769
Metar load time: 7
Navaid load time: 349
Airway load time: 726
Airport load time: 1770
Metar load time: 7
Navaid load time: 348
Airway
On Fri, Nov 28, 2008 at 10:18 AM, Yon Uriarte wrote:
Hi,
took a quick stab at navaid parsing. Also, i modified strutils::do_strip
to avoid calling string::operator[] excessively. Results:
Airport load time: 1769
Metar load time: 7
Navaid load time: 349
Airway load time: 726
Airport
hi,
those are 2 consecutive samples of the new navaid.dat parser. Compare with
the times in the previous posts. It has gone down from 520msec to 350msec.
Not a big difference on a fast machine, but it was a very easy change. On
slower machines it should add up.
greetings,
yon
On Fri, Nov 28,
Hi,
another little detail. In zfstream.cxx the input buffer for reading
buffered .gz files is set at page_size (4k). It is my understanding this
means files will be read at 4k chunks (uncompressed 4k). By changing the
multiplier to 16 (64k) or even 64 i could unscientifically measure a small
Yon Uriarte wrote:
Hi,
logstream.cxx:
Modified a bit the logstream implementation to avoid (stack) descent
down into (iostream) hell if we are not logging anything anyway. As it
is right now, it happily builds the string to print (iostream hell, deep
stacks, strings new/delete/copy)
On 26 Nov 2008, at 12:19, James Turner wrote:
strutils.cxx, simple..cxx, apt_loader.cxx
Accelerate parsing of apt.dat. As it stands it does aprox 5
(five) million wasteful new/delete pairs, mostly in the
strutils::split, vectorrunway growing and unnecessary string
initializations in the
On 27 Nov 2008, at 11:50, Yon Uriarte wrote:
I changed it a bit, too. Now it passes the runways to the
constructor and addRunways is private. But using swap sounds like
the solution. It'll need 2 vectors in the apt.dat main loop, one
with runways, the other one with taxis.
Right, I
Hi,
commenting inline. Im still programming a bit and measuring times. Patch
later.
On Wed, Nov 26, 2008 at 2:26 PM, Melchior FRANZ [EMAIL PROTECTED] wrote:
Hi,
* Yon Uriarte -- Wednesday 26 November 2008:
this is a patch to speed up startup times and some other
misc things.
Thanks
- Yon Uriarte a écrit :
Nothing i can do about that, let the CVS commiters pass a replace over
the files. MSVS is a hard master. Or is there an option to tell it not
to mess with my spaces?
Tools Options Text editor C/C++ Tabs
-Fred
--
Frédéric Bouvier
http://my.fotolia.com/frfoto/
Hi,
On Thu, Nov 27, 2008 at 9:53 AM, James Turner [EMAIL PROTECTED] wrote:
On 26 Nov 2008, at 12:19, James Turner wrote:
strutils.cxx, simple..cxx, apt_loader.cxx
Accelerate parsing of apt.dat. As it stands it does aprox 5
(five) million wasteful new/delete pairs, mostly in the
Hi,
this patch tries to speed up airways laoding. The strutils funcions are
meaningfully commened and renamed. It also does timings on the load times.
My results:
2 runs no changes wrt. to last patch:
Airport load time: 1607
Metar load time: 16
Navaid load time: 499
Airway load time:
Hi,
this is a patch to speed up startup times and some other misc things.
Please kindly try it out on your configurations. Commenting on each
file/change:
nasal/misc.h:
If p == 0 return, else call free(p). Dont go into the malloc lib for
nothing, probably free() does this check 1st thing in
Hi,
* Yon Uriarte -- Wednesday 26 November 2008:
this is a patch to speed up startup times and some other
misc things.
Thanks for taking care of that. Startup time is really a
problem, made worse by the fact that one has to restart
fgfs to use another aircraft.
I'll leave commenting on the
On 26 Nov 2008, at 11:14, Yon Uriarte wrote:
Hi,
this is a patch to speed up startup times and some other misc
things. Please kindly try it out on your configurations. Commenting
on each file/change:
logstream.cxx:
Modified a bit the logstream implementation to avoid (stack)
On Thursday 20 December 2007 01:07, Shad Young wrote:
Hi all,
Again not sure if I should post this to the users list.
I have been experimenting with the latest FG 1.0.0 on Win32 (XP
SP2) and am having some rather significant frame dropping.
FPS on or near the ground at San Fran in all AC
Frederic Bouvier wrote:
Selon Shad Young :
I tried to remove FG using the uninstall program and then cleaning out
the registry, deleting the folder etc, but it seems to be keeping the
settings that I had with FG 0.9.10 (is there an INI somewhere other than
in the FG folder in Program
Hi all,
Again not sure if I should post this to the users list.
I have been experimenting with the latest FG 1.0.0 on Win32 (XP SP2) and
am having some rather significant frame dropping.
FPS on or near the ground at San Fran in all AC often results in long
pauses and jumps, with regular
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I don't know where it is on windows but on Linux there is an xml in
$HOME/.fgfs/autosave.xml and for each aircraft $HOME/.fgfs/aircraft-data/*.xml.
Regards,
Arvid Norlander
Shad Young wrote:
Hi all,
Again not sure if I should post this to the
AnMaster wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I don't know where it is on windows but on Linux there is an xml in
$HOME/.fgfs/autosave.xml and for each aircraft
$HOME/.fgfs/aircraft-data/*.xml.
Regards,
Arvid Norlander
Shad Young wrote:
Hi all,
Again not sure
Selon Shad Young :
I tried to remove FG using the uninstall program and then cleaning out
the registry, deleting the folder etc, but it seems to be keeping the
settings that I had with FG 0.9.10 (is there an INI somewhere other than
in the FG folder in Program Files?)
Ok, I found the
Title: Performance monitoring
Can anyone tell me what the name of the routines is that allows one to determine the performance details of a Linux application?
Jon
---
Using Tomcat but need to do more? Need to support web services,
On Thu, 18 May 2006 10:58:26 -0500, Berndt, wrote in message
[EMAIL PROTECTED]:
Performance monitoring
Can anyone tell me what the name of the routines is that allows one to
determine the performance details of a Linux application?
..in the god old days way I use top, but there are way
Jon S. Berndt wrote:
Can anyone tell me what the name of the routines is that allows one
to determine the performance details of a Linux application?
It's probably best to start with gprof. Add a -pg argument to the
compiler flags for the application, run it, and then use the gprof
program to
On Thursday 18 May 2006 16:58, Berndt, Jon S wrote:
[HTML snipped...]
Can anyone tell me what the name
of the routines is that allows one to determine the
performance details of a Linux application?
Is it 'time' you're thinking of?
LeeE
On Thu, 18 May 2006, Berndt, Jon S wrote:
Can anyone tell me what the name of the routines is that allows one to
determine the performance details of a Linux application?
Depending on the application it might work to compile it with profiling
enabled using the gcc flag -pg:
-pg Generate
Jean-Yves Lefort wrote:
A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight:
See the attached patch (I think point-sprite and line-smooth should be
disabled by default).
Why, because an ancient video card can't display it properly?
If we go that way then please disable
On Mon, 06 Mar 2006 09:30:08 +0100
Erik Hofman [EMAIL PROTECTED] wrote:
Jean-Yves Lefort wrote:
A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight:
See the attached patch (I think point-sprite and line-smooth should be
disabled by default).
Why, because an
A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight:
point-spriteenhanced-lighting fps runway/taxiway lights
===
false false 18 steady pixels [1]
false
72 matches
Mail list logo
