Re: [Flightgear-devel] FlightGear 1.9.1
Hi Fred, saw your message asking for some testing. I decided to post a new thread asking for more user testing: http://flightgear.org/forums/viewtopic.php?f=2t=2812 grep -r getenv OpenSceneGraph, possibly relevant env vars, some of them are changed in my patches: F:\c\OSG\OpenSceneGraph\src\osg\DisplaySettings.cpp(356):if( (ptr = getenv(OSG_SERIALIZE_DRAW_DISPATCH)) != 0) F:\c\OSG\OpenSceneGraph\src\osg\DisplaySettings.cpp(369):if( (ptr = getenv(OSG_NUM_DATABASE_THREADS)) != 0) 1 by default, 2 may help a little bit on multi-cores. set to #cores F:\c\OSG\OpenSceneGraph\src\osg\DisplaySettings.cpp(374):if( (ptr = getenv(OSG_NUM_HTTP_DATABASE_THREADS)) != 0) 1 by default, fgfs uses none. set to 0 F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(805):const char* str = getenv(OSG_DATABASE_PAGER_PRIORITY); neutral by default: set to LOW F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(842):str = getenv(OSG_DATABASE_PAGER_GEOMETRY); F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(843):if (!str) str = getenv(OSG_DATABASE_PAGER_DRAWABLE); F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(872):if( (ptr = getenv(OSG_DELETE_IN_DATABASE_THREAD)) != 0) F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(929):if( (ptr = getenv(OSG_DO_PRE_COMPILE)) != 0) recently changed from default ON to OFF. set to ON F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(938):if( (ptr = getenv(OSG_MINIMUM_COMPILE_TIME_PER_FRAME)) != 0) F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(943):if( (ptr = getenv(OSG_MAXIMUM_OBJECTS_TO_COMPILE_PER_FRAME)) != 0) F:\c\OSG\OpenSceneGraph\src\osgUtil\Optimizer.cpp(61):const char* env = getenv(OSG_OPTIMIZER); is this applied to all objects? maybe i look into this. F:\c\OSG\OpenSceneGraph\src\osgUtil\RenderBin.cpp(108):const char* str = getenv(OSG_DEFAULT_BIN_SORT_MODE); may be relevant on some weird hw mixes. F:\c\OSG\OpenSceneGraph\src\osgViewer\ViewerBase.cpp(78):const char* str = getenv(OSG_THREADING); default SingleThreaded. set to CullThreadPerCameraDrawThreadPerContext regards, yon On Sun, Jan 11, 2009 at 11:55 PM, Frederic Bouvier fredfgf...@free.frwrote: - James Turner a écrit : On 11 Jan 2009, at 17:18, Frederic Bouvier wrote: My findings on that is that the pager thread needs to compile display list in the main loop, and this process is framerate dependent. At that time of the initialisation, there is only the splashscreen on screen, but its refresh rate slow down the loading process. For instance, I mesured it takes more than 1000 frames to display to correctly load a terrain tile. Maybe there are parameters to tweak, like the number of maximum display lists to compile each frames, and we could use more aggressive values until the scenery is displayed. Just a thought. Yon Uriarte has proposed a patch that limits the frame-rate to 60hz during the splash screen. Would that fix the issue, by freeing up cycles? The patch has been around since November and I ran it locally for many weeks without seeing any problems. As I understand it, if you limit the framerate, you limit the slots the pager has to compile objects, as compilation is done in the draw thread, between two frames. I tried to give more time and allow the compilation of more objects between two frames by calling setMinimumTimeAvailableForGLCompileAndDeletePerFrame and setMaximumNumOfObjectsToCompilePerFrame on the pager and on the renderer but for me it makes no difference (there is no problem for me, even in the Paris area ). That's why I built a Windows binary to allow people with the problem to test the possible solution. The binary is here : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun+fgfs-osg-win32-20090111.zip -Fred -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.9.1
Hi, On Mon, Jan 12, 2009 at 12:19 PM, Frederic Bouvier fredfgf...@free.frwrote: Hi Yon, I saw that but also saw that the osgViewer::Renderer has its own minimum time that is not settable by environment variable, and the resulting time is the minimum of the two values, one from the pager and the other from the Renderer ( both initially set to 0.001 ). oh, nice. In my test build I set large values until the scenery is loaded, then restore the default values. I had some numbers that i posted on this lists some weeks ago. At first i was limiting to 15fps and was loading slower than without limiting. Limiting to 50fps seemed to help. It also seems that large framerate ( more than 200 fps during splashscreen display, I even saw 600 at FSFO ) make the scenery load a bit longer. Curiouly, I see better loading time under Linux with an AMD Athlon XP 2400 and a NV FX5850, than under Windows with a Quad core i9450 and a GTX200. I am defragmenting my disk just in case. If those machines were dual boot, it'd be interesting to compare numbers with swaped OSs. Can you try with more than 1 osgdb thread? Also, osgDB pre-compile was disabled by default some weeks ago in osg. It seems you are tracing that code now, is it still doing some compile in the db threads? -Fred -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.9.1
Hi, all that can be set with environment variables. Best way would be to post on the forum asking for some testing. hth, regrads, yon On Sun, Jan 11, 2009 at 11:55 PM, Frederic Bouvier fredfgf...@free.frwrote: - James Turner a écrit : On 11 Jan 2009, at 17:18, Frederic Bouvier wrote: My findings on that is that the pager thread needs to compile display list in the main loop, and this process is framerate dependent. At that time of the initialisation, there is only the splashscreen on screen, but its refresh rate slow down the loading process. For instance, I mesured it takes more than 1000 frames to display to correctly load a terrain tile. Maybe there are parameters to tweak, like the number of maximum display lists to compile each frames, and we could use more aggressive values until the scenery is displayed. Just a thought. Yon Uriarte has proposed a patch that limits the frame-rate to 60hz during the splash screen. Would that fix the issue, by freeing up cycles? The patch has been around since November and I ran it locally for many weeks without seeing any problems. As I understand it, if you limit the framerate, you limit the slots the pager has to compile objects, as compilation is done in the draw thread, between two frames. I tried to give more time and allow the compilation of more objects between two frames by calling setMinimumTimeAvailableForGLCompileAndDeletePerFrame and setMaximumNumOfObjectsToCompilePerFrame on the pager and on the renderer but for me it makes no difference (there is no problem for me, even in the Paris area ). That's why I built a Windows binary to allow people with the problem to test the possible solution. The binary is here : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun+fgfs-osg-win32-20090111.zip -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Big black box
Hi, On Wed, Dec 31, 2008 at 12:06 PM, James Turner zakal...@mac.com wrote: I think we need to get a handle on the 'scenery loading takes 2 minutes' issue before doing a 1.9.1 Some weeks ago I was looking around the database thread and I got the impression all --random-objects are getting copied. As in each object is a full-blown copy, not an OSG node reference to a single instance of the object. I may be wrong, I was just reading around that part. Surely disabling random objects makes a great difference in load times, I never use random objects. I havent cvs updated in a few days, but merging both the use OpenThreads atomic and use display lists for shader trees would benefit win32 users and general fps. I'll see if I can merge soon and repost a patch. Completely wild guess - hitting a slow path in OSG or the driver due to some missing feature / unsupported extension? Since it does *eventually* start, if given long enough. James Happy new year :) yon -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG error
Hi, driver version? glxgears works? Please post the output of glxinfo. On Wed, Dec 31, 2008 at 8:17 AM, John Wojnaroski cas...@mminternet.comwrote: I recently setup a dual core 64-bit machine with FG-1.0 which works just fine. Now doing the same with a single core 64 bit machine. After instaling OSG-2.6.0 tried to run an example program and got the following error [cas...@rampart OpenSceneGraph]$ osgparticle Error: Unable to create OpenGL graphics context. GraphicsWindow has not been created successfully. Error: Unable to create OpenGL graphics context. GraphicsWindow has not been created successfully. Viewer::realize() - failed to set up any windows [cas...@rampart OpenSceneGraph]$ First time I've run across this problem. Haven't tried FG just yet, suspect this problem needs to be solved first. Linux is 2.6.23 with a Centos-5.1 package and a Nvidia GeForce 6200 on the MB. As best I can tell all the software is common across both machines, only discernible difference is that the dual-core machine is running with two PCIe video cards in twin view mode. Any suggestions where to look would be appreciated. John -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/math SGGeodesy.cxx, 1.8, 1.9
Hi, add#undef max #undef min at the top of that SGMisc.hxx, just before class ... I thought it was a local problem at my end cause I'm always changing things, heh. It's been that way for a few days. hth, yon On Sat, Dec 27, 2008 at 12:21 PM, Vivian Meazza vivian.mea...@lineone.netwrote: Hmmm, neither version compiles here with MSVC9. Gives the following error: source\simgear\math\SGMisc.hxx(27) : error C2059: syntax error : 'L_TYPE_raw' followed by hundreds of errors like this: 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing ')' before '}' 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing '}' before ')' Perhaps Fred has the answer Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More 3D cloud changes
Hi,
On Mon, Dec 15, 2008 at 10:20 AM, Tim Moore timo...@redhat.com wrote:
Yon Uriarte wrote:
Hi,
On Sun, Dec 14, 2008 at 6:12 PM, Heiko Schulz aeitsch...@yahoo.de
mailto:aeitsch...@yahoo.de wrote:
My last cloudset has fewer but larger sprites. I did this because I
noticed that it saves a lot of fps. On the forum Gijs noticed the
same with my cloudset.
Mores sprites means more alpha and more textures which is always a
fps-killer.
No, the cost of blending is proportional to the area blended on the screen,
so a
few large sprites vs. many small sprites should cost about the same. It is
true
that it takes longer to sort a large number of sprites, but I'm not worried
about the sorting cost at this point.
I am not too worried about the cost of sorting. I also (like you did)
tested doing a full sort each
frame (saving the matrix*vector in a vectordouble,int, sorting on the
saved double and
rendering on the index), something like this (not full patch):
CloudShaderGeometry.hxx:
struct sort_vector_element {
double dist;
int idx;
};
typedef std::vectorsort_vector_element sort_vector;
sort_vector _sortArray;
CloudShaderGeometry.cxx:
struct svp {
bool operator()(const CloudShaderGeometry::sort_vector_element a,
const CloudShaderGeometry::sort_vector_element b) {
return a.dist b.dist;
}
};
...
sort_vector svt;
svt = _sortArray;
if (skip_info-skip_count == 0)
{
osg::Matrix vm = state.getModelViewMatrix();
// Transform the viewing direction, represented by the eye space
vector (0,0,-1, 0), into model-space
// (here we simply take the opposite direction and reverse the
ordering when sorting)
osg::Vec3f view_dir(vm(0, 2), vm(1, 2), vm(2, 2)); // Caveat:
OpenSceneGraph matrices are transposed!
for(unsigned int i = 0; i _cloudsprites.size(); i++) {
sort_vector_element sar = svt[i];
sar.dist = view_dir*_cloudsprites[i]-position.osg();
sar.idx = i;
}
std::sort( svt.begin(), svt.end(), ssvp );
}
...
for(unsigned int i = 0; i _sortArray.size(); i++)
{
unsigned int idx = svt[i].idx;
sorted = sorted idx == _sortArray[i].idx;
const CloudSprite t = *_cloudsprites[idx];
GLfloat ua1[3] = { (GLfloat) t.texture_index_x/varieties_x,
(GLfloat) t.texture_index_y/varieties_y, t.width };
...
}
...
The high (really? not measured) math cost is the matrix*vector, which we
are doing on the full cloud vector
every time we do a bubble sort anyway. Might as well save it and do a quick
(hopefully) quicksort.
I suspect the rendering times are really increased by calls to glSomething.
We are resending
all the vertices every frame, incurring in a huge number of glSomeFunction
calls.
I've got a patch for trees using VBOs, performance gains are impressive,
allowing
thight forests with coverage/=10 (obj.cxx) (before hitting the win32 3G
limit in around 80 tiles, lol).
My idea was to adapt that VBO patch to cloud rendering, using index
buffers. The
vertex-packs (v,n,tc) are static and the index buffers have to be
recalculated
every frame (as in the quicksort above). Ideally one may just calculate
a static vertex-pack buffer for the whole cloud layer after it's generated
and either just draw indexed on that one huge vbo per cloud, or even better,
collect the indexes for each cloud, without drawing anything,
and then in a posterior renderbin draw that whole-layer indexbuffer
in a single rendercall (well, more than one glFunc, mapping the
vbos takes some calls). If I arrive at some results I'll post a patch :) im
doing
more than one thing atm.
I'm pretty sure that there is another solution looking to X-plane
which seems to use the same technic for their clouds.
Fewer bigger sprites with few parts of the sprite with 0 alpha 1.
One opaque pre-pass drawing front to back with
alpha culling != 1 and blending off to fill up z-buffer then a second
pass back to front with alpha culling 1 and blending on.
Second pass gets massively z-culled, saving on rop blending bandwidth.
First pass gets also z-culled by itself.
This is a good idea if, in fact, the cloud sprites are mostly opaque. I
think we
are doing various tricks where the sprites end up being completely
transparent.
Yup, rendering transparencies back to front incurs in massive overdraw.
Even if most of
the rendered cloud is either opaque or fully transparent we are
write-hitting the color and
z-buffers a proportionally (sp?) high number of times. And for 0alpha1
it's even worse,
a full read-write cycle to GPU ram.
One may hope that the GPUs are smart enought to auto-not-blend on alpha==0
or
alpha==1, I guess im an optimist. One of my older patches was not so
optimistic and
did an opaque pre-pass. At least the alpha 0+epsilon
Re: [Flightgear-devel] More 3D cloud changes
Hi, On Mon, Dec 15, 2008 at 6:00 PM, Heiko Schulz aeitsch...@yahoo.de wrote: Theory vs praxis ;-) I just tested it- no, more sprites = less fps Are you testing with drawing off? Where do I change the number of sprites? heh, so many .xmls What is your CPU? If you feel so inclined, try commenting out the part in CloudShaderGeometry.cxx that does the draw and measure the difference for say, doubling the number of sprites in a cloud, or multiplying it by 10. Sounds very promising! Attached. I saw some changes in pa24-250 and was, err, QA testing it, yeah. Nice one. OTOH bluebird was a bit uninteresting for me ;) I prefer unesco ufo. Anyway, from some comments in ShaderGeometry.cxx: --8---8--8 //if enabled: //no VBOs are created //- less RAM usage, a few less FPS //- more stutter //if not enabled //VBOs are created //- RAM usage explodes, easily noticed if tree coverage is multiplied (obj.cxx) //- a few more FPS //- less stutter // Notice that in both cases there is a memory penalty. The // memory will be allocated, either for the display list, possibly // in GPU memory, or in app RAM (and then copied to the GPU mem VBOs) //best subjective stutter results are: //VBOs ON //export OSG_COMPIlE_CONTEXTS=ON (notice small-case l) //export OSG_DO_PRE_COMPILE=ON #define CREATE_OWN_DISPLAY_LIST / // Ignore, some random testing. //#define USE_INTERLEAVED_ARRAYS // Use with this-setUseDisplayList(true), it will deallocate the array // after the 1st call (pre-compile or 1st draw). // So not multi-context safe. // If we manage our own VBO, we could use a single array // that we would free after the 1st draw or more likely // after it has been drawn/compiled on all GL contexts. // If we can get a list of context and we know that list // is static we can go this route and not suffer from RAM // usage explosion. // Also, if osgDB precompile was disabled (like in the Dec 15 2008 patch // to OSG) the memory would not be freed. We should force // pre-compile in that case to free the vertex-pack arrays memory // allocated on osgDB load --8---8--8 So, play with #define CREATE_OWN_DISPLAY_LIST This VBOs implementation will eat your RAM, specially if you run with obj.cxx: coverage /= 10.0; //10.0 is forests, 4.0 is ok for testing, 1.0 is default I was arriving at 3 GBs in 100km over forests (ufo). Alas, both with DL and VBOs i was running at 150fps+ (fov 120). Today's OSG patches disable pre-compile for osgDB objects. I suspect this will generate more stutter. I run with the config mentioned in the comments above, also, the default osgDB threads config (and the one we run with) is 1 osgDB pager thread and 1 osgDB HTTP pager thread. I sometimes run with the config: OSG_NUM_DATABASE_THREADS=3 OSG_NUM_HTTP_DATABASE_THREADS=0 Also, im running with the osgDB threads priority set to MIN (dual-core here). In closing: the display list implementation could be trivially merged. The VBOs stuff is more for the coders. If we can get the number of GL contexts both known and static, we can control the RAM usage of VBOs. greetings, yon trees-VBO-DL.patch.gz Description: GNU Zip compressed data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] tree rendering. was: More 3D cloud changes
Hi,
or one could even more trivially do:
Index:
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.hxx
===
---
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.hxx
(revision
96)
+++
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.hxx
(working
copy)
@@ -48,7 +48,7 @@
ShaderGeometry(int v) :
varieties(v)
{
- setUseDisplayList(false);
+ setUseDisplayList(true);
}
/** Copy constructor using CopyOp to manage deep vs shallow copy.*/
Index:
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.cxx
===
---
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.cxx
(revision
96)
+++
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.cxx
(working
copy)
@@ -39,7 +39,7 @@
{
extensions-glVertexAttrib1f(1, (float)
t-texture_index/varieties);
glColor4f(t-position.x(), t-position.y(), t-position.z(),
t-scale);
-_geometry-draw(renderInfo);
+_geometry-drawImplementation(renderInfo);
}
}
and get to use display lists, but with a fps deficit vs. the other DL/VBO
implementation. In this particular machine
it's 70fps vs. 150+. Maybe the attributes again?
greetings,
yon
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree rendering. was: More 3D cloud changes
Hi,
decided to test it - more weirdness, it's not the attributes, with this
patch (still using attributes) it runs at 150+fps.
Index:
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.hxx
===
---
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.hxx
(revision
96)
+++
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.hxx
(working
copy)
@@ -48,7 +48,7 @@
ShaderGeometry(int v) :
varieties(v)
{
- setUseDisplayList(false);
+ setUseDisplayList(true);
}
/** Copy constructor using CopyOp to manage deep vs shallow copy.*/
@@ -63,7 +63,7 @@
virtual osg::BoundingBox computeBound() const;
-void setGeometry(osg::Drawable* geometry)
+void setGeometry(osg::Geometry* geometry)
{
_geometry = geometry;
}
@@ -73,7 +73,7 @@
_trees.push_back(tree);
}
-osg::ref_ptrosg::Drawable _geometry;
+osg::ref_ptrosg::Geometry _geometry;
TreeBin::TreeList _trees;
int varieties;
Index:
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.cxx
===
---
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.cxx
(revision
96)
+++
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.cxx
(working
copy)
@@ -34,13 +34,48 @@
{
osg::State state = *renderInfo.getState();
const Extensions* extensions =
getExtensions(state.getContextID(),true);
+#if 1
+osg::Vec3Array *va = dynamic_castosg::Vec3Array*(
_geometry-getVertexArray() );
+assert(va ! ( va-size() % 4) );
+osg::Vec3Array *na = dynamic_castosg::Vec3Array*(
_geometry-getNormalArray() );
+assert(na ! ( na-size() % 4) );
+osg::Vec2Array *ta = dynamic_castosg::Vec2Array*(
_geometry-getTexCoordArray(0) );
+assert(ta ! ( ta-size() % 4) );
+const GLfloat *const va_raw = static_castconst
GLfloat*(va-getDataPointer());
+const GLfloat *const na_raw = static_castconst
GLfloat*(na-getDataPointer());
+const GLfloat *const ta_raw = static_castconst
GLfloat*(ta-getDataPointer());
+osg::Vec2 tc;
+glBegin(GL_QUADS);
+for(TreeBin::TreeList::const_iterator t = _trees.begin(); t !=
_trees.end(); ++t)
+{
+const GLfloat *vap = va_raw;
+const GLfloat *nap = na_raw;
+const GLfloat *tap = ta_raw;
+float tcoffset = (float)t-texture_index/varieties;
+for( unsigned int i=0; i va-size(); ++i) {
+glColor4f(t-position.x(), t-position.y(), t-position.z(),
t-scale);
+#ifndef TSG_PACKED_ATTRIBUTES
+extensions-glVertexAttrib1f(1, (float)
t-texture_index/varieties);
+glTexCoord2fv( tap ); tap += 2;
+#else
+tc.x() = tcoffset + *(tap++);
+tc.y() = *(tap++);
+glTexCoord2fv( tc.ptr() );
+#endif
+glNormal3fv( nap ); nap += 3;
+glVertex3fv( vap ); vap +=3;
+}
+}
+glEnd();
+#else
for(TreeBin::TreeList::const_iterator t = _trees.begin(); t !=
_trees.end(); ++t)
{
extensions-glVertexAttrib1f(1, (float)
t-texture_index/varieties);
glColor4f(t-position.x(), t-position.y(), t-position.z(),
t-scale);
-_geometry-draw(renderInfo);
+_geometry-drawImplementation(renderInfo);
}
+#endif
}
BoundingBox ShaderGeometry::computeBound() const
@@ -67,7 +102,7 @@
if ((fr[0].matchWord(geometry))) {
++fr;
iteratorAdvanced = true;
-osg::Drawable* drawable = fr.readDrawable();
+osg::Geometry* drawable =
dynamic_castosg::Geometry*(fr.readDrawable());
if (drawable) {
geom._geometry = drawable;
}
This could be merged. As it's the case that we are already dumping full
vertex-packs
to the GL we could avoid the attribute and use TSG_PACKED_ATTRIBUTES, as in
the
other patch.
yon
On Mon, Dec 15, 2008 at 9:22 PM, Yon Uriarte yon.uria...@gmail.com wrote:
Hi,
and get to use display lists, but with a fps deficit vs. the other DL/VBO
implementation. In this particular machine
it's 70fps vs. 150+. Maybe the attributes again?
greetings,
yon
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree rendering. was: More 3D cloud changes
Hi, ok, last tree-rendering patch spam. Using attached patch (with no attributes) and coverage /= 10.0 in obj.cxx: Result: ufo, v=0, 160fps: http://img266.imageshack.us/my.php?image=treessimpledlpatchbt7.jpg click on the image to zoom it. RAM usage seems to be under control. Go overheat your gpu :) greetings, yon trees-simple-DL.patch.gz Description: GNU Zip compressed data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More 3D cloud changes
Hi, On Sun, Dec 14, 2008 at 6:12 PM, Heiko Schulz aeitsch...@yahoo.de wrote: My last cloudset has fewer but larger sprites. I did this because I noticed that it saves a lot of fps. On the forum Gijs noticed the same with my cloudset. Mores sprites means more alpha and more textures which is always a fps-killer. I'm pretty sure that there is another solution looking to X-plane which seems to use the same technic for their clouds. Fewer bigger sprites with few parts of the sprite with 0 alpha 1. One opaque pre-pass drawing front to back with alpha culling != 1 and blending off to fill up z-buffer then a second pass back to front with alpha culling 1 and blending on. Second pass gets massively z-culled, saving on rop blending bandwidth. First pass gets also z-culled by itself. It's a tradeoff between cpu and gpu fill and blend rate, whatever is your bottleneck. Sadly, that changes between machines, so the opaque pre-pass should be a configurable. Regards HHS greetings, yon -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Traffic Files
Hi, On Sun, Dec 14, 2008 at 7:41 PM, Jon Stockill li...@stockill.net wrote: When importing the recently committed traffic files into the traffic database I've noticed that there is some duplication, for example: EC-HDT is defined for both CLI and IBE with different liveries. CLI: clickair, IBE: iberia, IIRC ibe bought cli recently. Jon greetings, yon -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
Maybe add an option to do full length bubble sort each update?Or quicksort, even. It should really be that much of a cpu eater, after the clouds are sorted. It would result in a bit of frame drop on pan around, but flickering would disappear. For users with modern system it would improve visuals. I'll test that later. greetings, yon On Wed, Dec 10, 2008 at 10:26 AM, gerard robin [EMAIL PROTECTED] wrote: On lundi 08 décembre 2008, Stuart Buchanan wrote: Curt wrote: I wonder if there is some sort of floating point resolution / rounding problem with the sort? I see a lot of flickering myself. Also if I look some particular direction and the clouds get sorted ok, then look away for even a second, and then look back (by changing the view direction) the clouds seem to have totally lost their previous correct sort and need to be sorted again ... but that doesn't happen until the clouds come back in view. I'm not sure what the sort criteria is, but it seems strange that the sort order would get messed up in a brief second of not having a particular set of clouds in view. One of the performance improvements introduced with the last patch is to re-use clouds rather than generating unique clouds for each position. This makes a significant performance difference on my system (about 5fps IIRC), but means that occasionally you end up between two instances of the same cloud, and the sprites need resorting as you change the view. You can avoid this by increasing the number of cloud types in the Rendering Options dialog, then toggling Enable 3D clouds to cause re-generation. At the moment the slider goes to 20, which minimizes the probability of hitting this issue. Obviously, we could increase the limit still further if required. -Stuart Hello Stuart, First thanks to you and to everybody who work on it. We have got now a huge improvement. However i am , now, a bit disappointed with these flickering ( too often, may be it is my graphics cards NVIDIA 7800 GS 512 mo) which decrease dramatically the result (mainly with Metar) . And which make me to come back to the 2D clouds, with the GUI preference. I can understand that, with that last patch you have tried to answer to the low cpu performance, when we are using old computers. It was the case with the old 3D clouds version and nobody apologized about it since we had ever the choice 2D clouds or 3D clouds. I did like better one of your previous version. Yes we had that ugly blue edge ( sometime only when we had a 2d Clouds layer behind), but now, i have blue edge randomly coming on and flickering, which is worth. Wont it be possible to have a version which will come to a better eye candy, even if it is more cpu eater. ? Greeting -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear Build - pthread.h, and alut.h
Hi, google for pthreads-win32 and freealut (iirc). HTH, regards, yon On Tue, Dec 9, 2008 at 2:37 PM, Fabian Grodek [EMAIL PROTECTED]wrote: Hello, Here's a noobie question about Simgear build (in VC++ 2005 Express Edition) I get messages that the files pthread.h and alut.h cannot be found. These files are called by #include statements in sgthread.hxx (v1.9) and sample_openal.cxx (v1.32) and .hxx (v1.23). Where could I find these files (pthread.h and alut.h)? A search in my whole system found nothing. Thank you. Fabian -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear Build - pthread.h, and alut.h
Hi, omg, im getting senile, my apologies. Alut is from the OpenAL package. I compile it from the OpenAL SVN repos and have yet to hear a single sound from fg. But it compiles and runs. I use pthreads-2-8-0, precompiled. hth, yon On Tue, Dec 9, 2008 at 2:48 PM, Yon Uriarte [EMAIL PROTECTED] wrote: Hi, google for pthreads-win32 and freealut (iirc). HTH, regards, yon On Tue, Dec 9, 2008 at 2:37 PM, Fabian Grodek [EMAIL PROTECTED]wrote: Hello, Here's a noobie question about Simgear build (in VC++ 2005 Express Edition) I get messages that the files pthread.h and alut.h cannot be found. These files are called by #include statements in sgthread.hxx (v1.9) and sample_openal.cxx (v1.32) and .hxx (v1.23). Where could I find these files (pthread.h and alut.h)? A search in my whole system found nothing. Thank you. Fabian -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 on win32 Usual content: o bigger zlib decompression buffer o nafree() returns if freeing NULL o throttle screen update rate on splash screen for single core machines o reduced memory usage for FGRunway o faster apt.dat, nav.dat awy.dat parsing My previous memory numbers were wrong, I was still using the buggy double taxiway allocation (I have 4 local copies of the code). With the SGAtomic changes and the reduced memory footprint of FGRunway the following memory usage was measured on ksfo (no random objects, win32), just running fgfs.exe, no params (i may have some non-standard preferences saved, they were the same for both runs anyway): original: 565MB this patch: 470MB Over some random terrain for which i have not downloaded terrain files and using ufo instead of c172: 338 231 This is after the splash screen disappears. The numbers oscilate +/- 10MB. It seems something is allocating and freeing memory just after loading. greetings, yon perf3.patch.gz Description: GNU Zip compressed data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 =
FGScenery::getPagerSingleton()-getFileRequestListSize();
char msg[60];
snprintf( msg, 59, loading scenery objects %2u / %2u, requests,
tocompile );
fgSplashProgress( msg );
}
fgRequestRedraw();
SG_LOG( SG_ALL, SG_DEBUG, );
}
For a nice little countdown of # of tiles left to load and compile.
greetings,
yon
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
Hi, reading the patch, in the callback: fogC[3] = 0.0; I believe this sliped from my testing, not sure if it's needed. I was doing some alpha-channel tests. If it works with this set, all is fine :) greetings, yon On Sat, Dec 6, 2008 at 11:35 PM, Stuart Buchanan [EMAIL PROTECTED] wrote: I wrote: Hi All, Attached is what I'm hoping will be the final 3D clouds patch. Nope, it wasn't attached, because I hit Send rather than Attach. This time it is attached. Sorry for the noise. It does the following: - Replaces simple shader attributes with vectors (this was missed out of the last patch by mistake) - Includes Yon's Fog update code (Thanks!) - Fixes a bug since 1.0 where --enable-real-weather-fetch stopped the other weather scenarios from working. Let me know of any bugs. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yet another Clouds Patch (again)
Hi,
osg::ref_ptrGeode SGNewCloud::genCloud() {
...
+GeodeList* g = (*iter).second;
+
+if (iter == cloudMap.end() || g-size() num_flavours)
...
dereferencing iterator::end is a no-no (it's not standard c++).
suggest:
GeodeList* g;// = (*iter).second;
if (iter == cloudMap.end() || (g=(*iter).second)-size()
num_flavours)
Also, cull is thru the roof and it looks much nicer :)
greetings,
yon
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yet another Clouds Patch (again)
Hi Stuart, a little patch for the update callback, this time in a readable and #ifdef'ed format. The update time goes down from 10ms to 1ms on this machine. Fog is still applied. Bonus: trivial patch for annoying unsigned warnings. greetings, yon clouds.patch Description: Binary data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 payload. After reading the docs on InterlockedIncrement (they say a 4 byte align is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs? Somebody has recently switched some threading stuff over to OSG's classes, I wonder if we should throw out SGAtomic, SGReferenced, and SGSharedPtr in favor of OSG's implementation. Coincidentally, OpenThreads::Atomic doesn't have that align, it simply has a volatile long and presumably it works fine. -- Csaba/Jester Excellent idea. With the patch and some other changes it saves 100MB over terrain, less over ocean. That's just after the scenery has finished loading, should be more over time. greetings, yon referenced.patch Description: Binary data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 bytes) measured with procexp.exe after scenery finishes loading. CVS: 499MB patched: 431MB hmm, over ocean: 291 361 hmm, i dont know what i measured before, maybe some other memory counter? my bad. Seems it is only saving around 70MB (on windows, unixes already have part of this memory saving). greetings, yon On Fri, Dec 5, 2008 at 5:28 PM, James Turner [EMAIL PROTECTED] wrote: On 5 Dec 2008, at 16:01, Yon Uriarte wrote: Excellent idea. With the patch and some other changes it saves 100MB over terrain, less over ocean. That's just after the scenery has finished loading, should be more over time. Good gracious. 100MB? That seems almost impossibly large. This is a change that needs to be pretty widely tested, but it sounds like a great improvement. James -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 overall nicer. 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 reduced precision on FGRunway members (double for length?) i was able to reduce sizeof(FGRunway)(win32) from 256 to 192. I would prefer not to reduce precision - I don't think the memory savings warrant it, and at least on some machines, the compiler is forced to generate many float-double or double-float conversions. FGRunway is not efficient for size, but it's not costing us anything in real terms - unlike the start up time. Around 30MB. Didnt know you where working on changing the airport load code. Going for 8.50? IMHO there is little point in keeping the runway length in doubles. It's seldom used, it's just putting pressure on the swap trigger. We let pass 30MB here, 30MB there, 2 seconds here, .8 there and it adds up. I try to consider a 1Ghz pentium 3 with 1GB RAM as an oldish machine target that may run fg. Not to nitpick, im glad i can give something to fg. The startup time is what catched my attention even before taking off the ground :) And, again, I have pending work in this area that makes all of these issues go away completely, so unless there's an immediate benefit for the 1.99.x release, I would focus on some other area. I will, thanks for the hint. I can test your airport code, profile it and gladly nitpick on it's memory/cpu use ;) I've been considering changing the load code for apt and nav to use strod. Apparently sometimes atof is implemented as a wrapper of strod (dinkumware.com, dont know what the man pages say). It would save the walking copy of the line for spliting and some atof overhead. It would produce the typical char *p inner loop :) But im having fun with the 3dclouds and osg, so maybe later. 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 is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs? Can't comment on that, I'm on GCC 4.0 on Mac where SGAtomic is falling-back to pthreads :( Here's my patch (including yours) to src/Airports: thanks Regards, James greetings, yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yet Another Clouds Patch
Hi again Stuart, this patch reduces draw time from 4.2ms to 3.0ms on my system. Middle of the ocean, ufo, feet, v=0. Seems the # of attributes is awfully expensive, at least on ATI/win32. The changes are #ifdef'ed for easy testing. greetings, yon clouds3d.packed.attributes.patch Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 reduced precision on FGRunway members (double for length?) i was able to reduce sizeof(FGRunway)(win32) from 256 to 192. 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 is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs? Thanks again, attached is a patch for the patch. May I ask for your patch? greetings, yon On Thu, Dec 4, 2008 at 2:38 AM, James Turner [EMAIL PROTECTED] wrote: On 1 Dec 2008, at 18:20, James Turner wrote: I will apply and test, sadly I am in the same situation as you for getting patches applied :) I've tested the apt loader / string split / patch, and everything seems to work - though I've complicated things by refactoring the runway / taxiway creation, to fix some style issues, and resolve a couple of problems: taxiways don't need a reciprocal created (and it's wasteful to do so), and runways weren't getting their airport set, which crashed some local code of mine. Regards, James perf2.patch.gz Description: GNU Zip compressed data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yet Another Clouds Patch
Hi Stuart, I like the 3dclouds, so i took a look at them. This is a patch for you and maybe some brave developer. It's really not usable. First, some notes. Please excuse the telegram-like prose, I can barely read them myself now - UFO # calls to void CloudShaderGeometry::drawImplementation(RenderInfo renderInfo) const after X frames circles, diameter aprox one cloud square, i guess: 130k in 80k try resort 50k resort 50/130 ratio: 30% straight, v 900 136k in 5k try resort 4k resort 4/136 ratio: 2,9% straight, v 240 127k in 1.8k try resort 566 resort 566/127k ratio: 0,44% --- drawable.updateCallback has the same problem, too many calls per frame (aprox 19440) resulting in a 10ms update time. Normal low is 1ms. Curiosly the draw callback, which is done at the same frequency per frame takes less time (approx. 6ms or less) which may indicate a heavy overhead from the scenegraph walking. drawImplementation is called approx 163 times per frame (v=0), the drawable/CloudshaderGeometry.updateCallback 19440. The cloudshadergeometry sets are repeated in a 3x3 grid, that explains the 9x factor (2160x9 = 19440). drawImplementation is called only for culled (visible, non-culled) clusters. options to use display lists: - update callback to pre-sort, dirty display list in update callback - has excessive update callbacks (unculled stuff gets called). - implement part of the display-list logic in drawimplementation - same number of callbacks as before, must set _geometry-usedisplaylist = false - relatively small gains, can hiccup - i expect performance to be strongly dependant on driver revision VBO: - static vertex data, dynamic index - resort only index array - update dynamic data on dirty (sorting changed) - ? use a single VBO for all clouds in all CloudShadersGeometry - Let me try to translate the telegram from mars: I did a quick performance on the resorting behaviour. UFO, flying at different speeds or in circles. After N frames i checked the hit-counts on the breakpoints. Then some sort-hit ratios were calculated. It seemed like a display-list could be useful, seeming not too often are clusters resorted. 1st try (is in the patch, but disabled) was to sort in the update traversal and use the default display list implementation (overriding virtual Drawable::drawImplementation). This lead to an impressive performance drop. Update callback is called for each cluster attachment in the graph. Each cluster is attached an extra 9x. I guess 2160 is the static cloud field size. So instead of only getting called on non-culled visible clusters it was called on each cluster, 9x each :) Same thing is happening in CVS right now: SGCloudFogUpdateCallback is called 19k times per frame to update a single stateset. One time per frame is enough, this drops my update time from 10ms to 1ms. I noticed that there were some periodic rises in the draw time (clouds callback), adding a random jitter: skip_info-skip_limit += rand() 3; seems to take care of that part. In the patch it's in the wrong place, it should be inside the if-block above it. Next i implemented a display list (#define CSG_USE_DISPLAY_LISTS). Results were unsatisfactory. Draw time increased. Even when just calling the display list the draw time is higher. This is disconcerting considering _geometry is drawn with a display list by default (AFAIK). Display lists are only regenerated after a non-resort after a resort to avoid the costly regeneration of the display list every consecutive sort. I considered maybe it was a fill-rate problem. The patch does attach the cloud fields twice. Once it's rendered front to back, only the opaque part, no blending, normal bin. Then it's rendered back to front with blending (as usual). Performance was similar (Radeon 3870). I then avoided the call to _geometry-draw, suspecting something was costly there. I used some simple glVertex calls to generate similar, smaller, quads. Same results, not faster. I'm confused about these results. I must have made some programming error, but even then display lists could be faster than pure glVertex. The next approach should be to set up a VBO with all the vertex data and attributes for the whole cloud field and only update the index array when resorting. Less data to transmit to the GPU and 1 single opengl call per cluster or even per layer. The VBO changes are bigger than what I'm willing to do right now. Sorry. Parts of the code are #if 0 #else #endif, i use that to quickly try out different combinations. The display list part is not compatible with opaque pre-render, #if 0/1 out as apropiate. Ignore the changes to the GLSL programs. Anyway, some of this code (fog update, jitter) could be integrated. The rest could be useful for your experimenting. The patch comes directly off my
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
Hi, On Sun, Nov 30, 2008 at 8:08 PM, Stuart Buchanan [EMAIL PROTECTED] wrote: I note that the base package size above is 200MB. I did a quick look at the (uncompressed) size in KB of each of these aircraft, excluding the CVS directories. 5564777-200 6208b1900d 13528 bocian 17708 c172p 6752dhc2 20656 Concorde 876 Dragonfly 29428 f-14b 4360CitationX 14464 sopwithCamel 232 ufo 2148ZLT-NT 3968A6M2 We can reduce the on-disk plane footprint. I did a quick test compressing f-14b/Models/common2.rgb (texture atlas with fuselage skin, it seems): baseline common2.rgb: 792k png common2.png: 295k (irfanview, best png compression, keep transparent color ON) ziped common2.zip: 375k (winrar .rgb, best zip compression) rared common2.rar: 353k (winrar .rgb, best rar compression) So there seems to be a case for converting all .rgb to .png. It should result in a smaller distribution and a smaller disk footprint (possibly quicker loading 1st time loading). It is my naive understanding that the references to .rgb should only be in .xml and .ac files. A quick shell script could find all .rgb convert them to .png, do a search replace on .xml and .ac files and then commit to cvs. Also i looked into a .AC file to confirm they are text and a /bin/sed search replace is possible. My 1 sample size research file f-14b.ac is 2485k uncompressed, 337k compressed as rar (winrar, best rar compression). I would even expect gzip to achieve a better compression ratio. Again, it should be possible to compress all .ac, either as a pre-pass on installer generation or to commit it to cvs. The OSG AC loader may need patching to load .gz files, I ignore if the osg loader can do the gz streaming itself on all supported file types. greetings, yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 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) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) I've reworked the logstream changes a bit and checked this in. Thanks. Nice. It is still doing a pointless function call. No. Your request to don't use it in the global constructors is not sufficient. Shouldnt matter too much performance wise anyway :) 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 sufficient. I'd like to ask for them to get tested and eventually applied. I'll keep resubmiting them at 1 week intervals :) greetings, yon loader.patch.rar Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 gzip input buffer to 64k (was 4k). I believe all of them make sense and are sufficient. I'd like to ask for them to get tested and eventually applied. I'll keep resubmiting them at 1 week intervals :) I will apply and test, sadly I am in the same situation as you for getting patches applied :) James haha, thank you. What's your patch about? Maybe we can swap patch tests :) yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 of them make sense and are sufficient. I'd like to ask for them to get tested and eventually applied. I'll keep resubmiting them at 1 week intervals :) did some timings on the throttle patch to try and market it :) I got some unexpected results: All times in ms, dual-core pentium E2xxx @3.1GHz Affinity set to simulate single-core with: start /affinity 0x1 /B fgfs ... Throttle at 15fps throttled, no random objects, no affinity. 4096 4078 4074 not throttled, no random objects, no affinity 3029 3217 3012 throttled, no random objects, affinity 0x1 5498 5435 5457 not throtled, no random objects, affinity 0x1 4556 4502 4482 throttled, enabled random objects, no affinity 30009 29532 29005 29988 not throttled, enabled random objects, no affinity 38285 37927 37958 throttled, enabled random objects, affinity 0x1 33749 33518 34116 not throttled, enabled random objects, affinity 0x1 61120 57412 58443 it is faster for random objects (target case), but slower for all other cases. I suspect the osgDB threads are blocking waiting for the frame to upload their display lists. Anyway, throttled to 50fps now I get: throttled 50 , no random objects, no affinity 3176 3187 3168 throttled 50 , random objects, affinity 0x1 38455 37583 38273 Please set the frame limiter to 50, not15, when testing, I'll set it to that in next week's patch. yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) I've reworked the logstream changes a bit and checked this in. Thanks. Nice. It is still doing a pointless function call. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 meaningfully commented 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: 1170 Airport load time: 1607 Metar load time: 16 Navaid load time: 483 Airway load time: 1185 --- after changes to airways loader. Airport load time: 1622 Metar load time: 8 Navaid load time: 499 Airway load time: 690 Airport load time: 1614 Metar load time: 8 Navaid load time: 505 Airway load time: 689 Airport load time: 1610 Metar load time: 8 Navaid load time: 498 Airway load time: 689 Airport load time: 1664 Metar load time: 8 Navaid load time: 510 Airway load time: 699 Airport load time: 1684 Metar load time: 7 Navaid load time: 513 Airway load time: 684 -- Then i noticed i had the files (*.dat) unpacked because i'd been peeking at the contents. After repacking i got the following times: Airport load time: 1806 Metar load time: 7 Navaid load time: 526 Airway load time: 732 Airport load time: 1790 Metar load time: 7 Navaid load time: 522 Airway load time: 721 Airport load time: 1793 Metar load time: 7 Navaid load time: 528 Airway load time: 721 greetings, yon On Thu, Nov 27, 2008 at 11:58 AM, Frederic Bouvier [EMAIL PROTECTED] wrote: Tools Options Text editor C/C++ Tabs Thank you, i hope there are no evil tabs now. flightgear-patch.rar Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 load time: 728 greetings, yon On Fri, Nov 28, 2008 at 11:09 AM, Yon Uriarte [EMAIL PROTECTED] wrote: 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 meaningfully commented 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: 1170 Airport load time: 1607 Metar load time: 16 Navaid load time: 483 Airway load time: 1185 --- after changes to airways loader. Airport load time: 1622 Metar load time: 8 Navaid load time: 499 Airway load time: 690 Airport load time: 1614 Metar load time: 8 Navaid load time: 505 Airway load time: 689 Airport load time: 1610 Metar load time: 8 Navaid load time: 498 Airway load time: 689 Airport load time: 1664 Metar load time: 8 Navaid load time: 510 Airway load time: 699 Airport load time: 1684 Metar load time: 7 Navaid load time: 513 Airway load time: 684 -- Then i noticed i had the files (*.dat) unpacked because i'd been peeking at the contents. After repacking i got the following times: Airport load time: 1806 Metar load time: 7 Navaid load time: 526 Airway load time: 732 Airport load time: 1790 Metar load time: 7 Navaid load time: 522 Airway load time: 721 Airport load time: 1793 Metar load time: 7 Navaid load time: 528 Airway load time: 721 greetings, yon On Thu, Nov 27, 2008 at 11:58 AM, Frederic Bouvier [EMAIL PROTECTED] wrote: Tools Options Text editor C/C++ Tabs Thank you, i hope there are no evil tabs now. fg.rar Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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, 2008 at 5:25 PM, Curtis Olson [EMAIL PROTECTED] wrote: 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 load time: 1770 Metar load time: 7 Navaid load time: 348 Airway load time: 728 Am I misreading your stats? There doesn't seem to be any significant different between your two sets of timing data (?) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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
gain. I believe gzstream is used for terrain loading, too. I guess a value
of 16*page_size should be adecuate, not too small, small enough that it
might stay in the cache for the caller to process. This should save on
system calls, too.
Non scientific measurements, twice for each size:
original, 1 page buffer:
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 load time: 728
istream.gz buffer from 1 to 16 pages size
Airport load time: 1746
Metar load time: 7
Navaid load time: 343
Airway load time: 716
Airport load time: 1742
Metar load time: 8
Navaid load time: 343
Airway load time: 724
at 64 pages
Airport load time: 1728
Metar load time: 7
Navaid load time: 344
Airway load time: 720
Airport load time: 1736
Metar load time: 7
Navaid load time: 345
Airway load time: 728
Patch:
Index: zfstream.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/misc/zfstream.cxx,v
retrieving revision 1.5
diff -u -r1.5 zfstream.cxx
--- zfstream.cxx 25 Jul 2008 18:35:42 - 1.5
+++ zfstream.cxx 28 Nov 2008 17:15:05 -
@@ -42,7 +42,7 @@
ibuffer(0)
{
// try {
-ibuf_size = page_size / sizeof(char);
+ibuf_size = 16*(page_size / sizeof(char));
ibuffer = new char [ibuf_size];
// } catch (...) {
//delete [] ibuffer;
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 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 nasal, runway, and osg changes to the respective maintainers and focus on one thing: +++ misc/strutils.cxx 24 Nov 2008 17:13:29 - [...] /** +* Avoid new/delete/cpconstructor clusterfsck +*/ + int + split_whitespace_aptdat( const string str, int maxsplit, vectorstring res ) [...] + split_aptdat( const string str, const char* sep, int maxsplit, vectorstring res ) This is IMHO not acceptable! 1) If these functions are meant to be better than the existing split()/split_whitespace(), then they have to replace them. If they are different and customized for dealing with Robin PEEL's apt.dat file (as the name implies), then they have no place in SimGear. This is a set of generic libraries, and not (supposed to be) tied to FlightGear, let alone to Robin's DB. I've renamed the functions and added meaningful comments. 2) The function head focuses on what the function doesn't do (avoids), rather than on what it does. If you think split()/split_whitespaces() are fscking something up, then please explain why you think they should keep doing that. No, i dont think they should keep doing that. In the context of the file it's written in (strutils.cxx) you can easily compare the 2 functions and calculate in your head why the others are a cluster thing. 3) We value the coolness factor of f-words rather low, even when they are disguised as acronyms for file system check. Hey, even the use of WTF is prohibited to my disappointment. (Whoops. :-) WTF?? why? we are adults. Whatever, adult words removed. BTW: you introduced tabs in files that are space-indented, and even in a way that only works with 4-position tabs, rather than the standard: 8 positions. 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? m. greetings, yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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 strutils::split, vectorrunway growing and unnecessary string initializations in the main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) Excellent. I've been doing some similar work in that area (not yet ready for mass consumption) and also noticed the Ypenburg issue :) From a code aesthetic point of view, I can't say I like the extra runway count and taxiway count arguments to addAirport, but I appreciate the heap-traffic savings of getting the arrays correctly sized. Just had a thought here - it should be possible to use std::vector::swap() to pass in std::vectorFGRunway*, and avoid the ugly 'count' arguments. I'll do up a patch for this today/tonight. 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. I agree with Melchior's comments about putting apt.dat specifics into SimGear, the split helpers can happily live in apt_loader.cxx. That way we'll know to delete them if I ever replace the file format. Changed the name to split_inplace and patching airways parsing to use it. Still testing and timing. Possibly will look at the fix parsing, too, it's slowish. Regards, James greetings, yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
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: 1170 Airport load time: 1607 Metar load time: 16 Navaid load time: 483 Airway load time: 1185 --- after changes to airways loader. Airport load time: 1622 Metar load time: 8 Navaid load time: 499 Airway load time: 690 Airport load time: 1614 Metar load time: 8 Navaid load time: 505 Airway load time: 689 Airport load time: 1610 Metar load time: 8 Navaid load time: 498 Airway load time: 689 Airport load time: 1664 Metar load time: 8 Navaid load time: 510 Airway load time: 699 Airport load time: 1684 Metar load time: 7 Navaid load time: 513 Airway load time: 684 -- Then i noticed i had the files (*.dat) unpacked because i'd been peeking at the contents. After repacking i got the following times: Airport load time: 1806 Metar load time: 7 Navaid load time: 526 Airway load time: 732 Airport load time: 1790 Metar load time: 7 Navaid load time: 522 Airway load time: 721 Airport load time: 1793 Metar load time: 7 Navaid load time: 528 Airway load time: 721 greetings, yon On Thu, Nov 27, 2008 at 11:58 AM, Frederic Bouvier [EMAIL PROTECTED]wrote: Tools Options Text editor C/C++ Tabs Thank you, i hope there are no evil tabs now. FlightGear - Copy (2).patch Description: Binary data SimGear - Copy (2).patch Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance and initialization patch
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 most implementations, no need to test the malloc library. p == 0 happens, checked with debugger. 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) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) 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 main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) fg_os_osgviewer.cxx: Any particular reason to not run osg multithreaded as default? ViewPartitionNode, CameraGroup: Small compile fix for a OSG version with float matrices, instead of double. Tried to compile with float matrices to see if it affects speed, but the quantization is visible (aprox .5m) and the airplane jitters horribly. main.cxx: While showing the splash screen, limit the frame rate. I was getting 200fps at the splash screen, which is pointless wasteful, specially on single-core machines. On multicore one core is pegged at 100%, another is loading tiles. If you run with VBLANK on, on a fast single-core machine, it may not matter too much. Anyway, 15Hz redraws should be enough, quite possibly as low as 5Hz could be acceptable. Older computer owners should notice a difference. positioned.cxx: I dont know what this was for. I think it was a compile fix. I have some other changes to the codebase around, had to edit the patch files. Dont apply if everything else compiles for you :) The most important changes are the apt.dat optimization, the logstream optimization and the splash screen throttling. On this 3Ghz dual core intel E2160 with hot disk-caches and --disable-random-objects --disable-sound --aircraft=ufo it takes 6 seconds to start loading scenery tiles and 12 seconds to splash screen fade out. Airway loading is 1 second and does quite a few new/deletes, too. Maybe I´ll take a look at it. Going forward another big config issue I see is --enable-random-objects tile loading. It's orders of magnitude slower than with random-objects disabled. I'll try to take a look at it, but's all the osgDB implementation and it's big. Also, the tile loader is not concurrent, only one tile is loaded at a time. I can start 20 osgDB threads and only one of them will do anything useful. This is specially noticed with --enable-random-objects. As an interim solution it should be possible to start some threads to do the random objects addition after the base tiles have been loaded and displayed, later adding the subgraphs to the already displaying tiles and using more than one core to do the heavy random object generation. regards, yon FlightGear - Copy.patch Description: Binary data SimGear - Copy.patch Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
