[osg-users] how to disable FBO extension
I'd like to disable the usage of the FBO extension at runtime. I tried setting the OSG_GL_EXTENSION_DISABLE env var, but it didn't work. Looking into FrameBufferObject.cpp, it seems that it is directly loading the required functions via setGLExtensionFuncPtr and only consults the isGLExtensionSupported for the GL_EXT_packed_depth_stencil. Am I reading this right, is it intentional, and how do I disable the FBO extension then? -- Thanks, Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] compile error in osgwrapper_osgUtil PrintVisitor
Hi Robert! Another user reported this, but my nightly build also exhibits the same problem. Details here: http://www.cdash.org/CDashPublic/viewBuildError.php?buildid=14829 As we don't really need wrappers, this is just for your information in case you missed it. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] division by zero in osgParticle/FluidProgram.cpp
On Fri, Mar 13, 2009 at 11:16 AM, Robert Osfield
robert.osfi...@gmail.com wrote:
Hi Csaba,
Thanks for the fix. This helps me understand the nature and location
of the problem. Reviewing the changes and the original code I'm
thinking it might be simpler to just refactor the code block so the
division by wind_accel.length2() could be delayed, and have the if ()
statement refactored by moving the divisor to the other side of the
expression :
double compenstated_dt = dt;
if (relative_wind.length2() dt*dt*wind_accel.length2())
{
double critical_dt2 =
relative_wind.length2()/wind_accel.length2();
osg::notify(osg::NOTICE)** Could be critical:
dt=dt critical_dt=sqrtf(critical_dt2)std::endl;
compenstated_dt = sqrtf(critical_dt2)*0.8f;
}
Does this change make sense to you? If wind_accel.length2() is zero
then the division will never take place, chances of an overflow should
be avoided as well.
Hi Robert,
yeah, looks good. I have tried to come up with something similar, but
I didn't like my solution.
I wonder if the double calls to length2() get optimized by the
compiler, maybe it would be more efficient to store them in a
temporary variable. Also depends on how often the condition is true,
but shouldn't hurt.
The changed file is attached, could you try this
out on your models/app. I've done the standard example tests here and
they all work, but then they never highlighted a error so I can't
confirm a fix.
This should definitely avoid the division by zero, as you say, but
since the problem only occurs randomly for us I can not directly
verify right away.
--
Thanks,
Csaba
#include osgParticle/FluidProgram
osgParticle::FluidProgram::FluidProgram():
Program()
{
setFluidToAir();
}
osgParticle::FluidProgram::FluidProgram(const FluidProgram copy, const osg::CopyOp copyop):
Program(copy, copyop),
_acceleration(copy._acceleration),
_viscosity(copy._viscosity),
_density(copy._density),
_wind(copy._wind),
_viscosityCoefficient(copy._viscosityCoefficient),
_densityCoefficient(copy._densityCoefficient)
{
}
void osgParticle::FluidProgram::execute(double dt)
{
const float four_over_three = 4.0f/3.0f;
ParticleSystem* ps = getParticleSystem();
int n = ps-numParticles();
for (int i=0; in; ++i)
{
Particle* particle = ps-getParticle(i);
if (particle-isAlive())
{
float radius = particle-getRadius();
float Area = osg::PI*radius*radius;
float Volume = Area*radius*four_over_three;
// compute force due to gravity + boyancy of displacing the fluid that the particle is emersed in.
osg::Vec3 accel_gravity = _acceleration * ((particle-getMass() - _density*Volume) * particle-getMassInv());
// compute force due to friction
osg::Vec3 velBefore = particle-getVelocity();
osg::Vec3 relative_wind = particle-getVelocity()-_wind;
osg::Vec3 wind_force = - relative_wind * Area * (_viscosityCoefficient + _densityCoefficient*relative_wind.length());
osg::Vec3 wind_accel = wind_force * particle-getMassInv();
double compenstated_dt = dt;
double relative_wind_length2 = relative_wind.length2();
double wind_accel_length2 = wind_accel.length2();
if (relative_wind_length2 dt*dt*wind_accel_length2)
{
double critical_dt2 = relative_wind_length2/wind_accel_length2;
osg::notify(osg::NOTICE)** Could be critical: dt=dt critical_dt=sqrtf(critical_dt2)std::endl;
compenstated_dt = sqrtf(critical_dt2)*0.8f;
}
particle-addVelocity(accel_gravity*dt + wind_accel*compenstated_dt);
}
}
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] division by zero in osgParticle/FluidProgram.cpp
On Thu, Mar 5, 2009 at 4:16 AM, Csaba Halász csaba.hal...@gmail.com wrote: Hi! If wind_accel has zero length, then line 43 double critical_dt2 = relative_wind.length2()/wind_accel.length2(); will attempt a divide by zero. A simple fix would be to check for zero but that would still leave the possibility of an overflow if the divisor is small. So a more clever check would be nice. Any suggestions? Sorry for the UP, but with a planned 2.8.1 bugfix release, I wonder if at least the trivial fix for this could be applied, if nobody has a better idea. Same goes for the other div-by-zero I reported. -- Csaba/Jester ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] division by zero in osgParticle/FluidProgram.cpp
On Thu, Mar 12, 2009 at 5:04 PM, Tomlinson, Gordon gtomlin...@overwatch.textron.com wrote: Read this page http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol Looks the same as last time :D I haven't made a submission, because I was hoping for some discussion and a more sophisticated fix than just sticking an if (wind_accel.length2() 0) in there. -- Csaba/Jester ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] division by zero in osgParticle/FluidProgram.cpp
On Thu, Mar 12, 2009 at 6:03 PM, Robert Osfield robert.osfi...@gmail.com wrote: HI Csaba, I don't have any strong opinions on these issues, as I'm not very familiar with the code, and haven't seen problems first hand with the code segments your pointing out so don't have any extra insight to provide. I don't know if you are directly seeing bugs, or just come across potential problems in a code review. Yeah, division by zero causes SIGFPE if exceptions are enabled. Otherwise it produces NaNs that aren't nice either :) As you're the first person to point to these potential problems I can only presume that you have a particular usage model that highlights them, this does place you in the best place to come up with a fix and qualify that they are fixed. As Gordon mentioned, if you do come up with a fix post them to osg-submissions and then I can review them. The problem is that I have no idea what this critical_dt means and I am also not familiar with best practices in floating-point calculations. I am pretty sure checking for 0 will fix the divide by zero, but it still leaves other bugs lurking. I just wanted to make sure the issue is known and give a chance to any experts to come up with a proper fix. I personally hate to fix things twice, if they could have been fixed properly the first time around. But okay, I will submit the 0-check, then. Better than the current state, anyway. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] fonts
On Mon, Mar 9, 2009 at 7:23 PM, Paul Shabash osgfo...@tevs.eu wrote: Hello, When I try to create text, I get the following error message: Warning: Could not find plugin to read objects from file C:\Windows\Fonts\arial.ttf. Does anyone know which plugin that's referring to and why? I believe you need osgdb_freetype. -- Cheers, Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] division by zero in include/osgDB/DatabasePager
Hi!
More division by zero trouble, this time in
include/osgDB/DatabasePager line 331:
double getAverageTimeToMergeTiles() const { return
_totalTimeToMergeTiles/static_castdouble(_numTilesMerges); }
Obviously divides by zero if _numTilesMerges is zero.
--
Csaba
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] division by zero in osgParticle/FluidProgram.cpp
Hi! If wind_accel has zero length, then line 43 double critical_dt2 = relative_wind.length2()/wind_accel.length2(); will attempt a divide by zero. A simple fix would be to check for zero but that would still leave the possibility of an overflow if the divisor is small. So a more clever check would be nice. Any suggestions? -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Curious osgText crash
On Mon, Mar 2, 2009 at 6:33 PM, Kim C Bale k.b...@hull.ac.uk wrote: Occasionally this will run, but the majority of the time it bombs. If one of you kind ladies or gentlemen could run it and tell me if you get the same error/crash I would most grateful. I'm afraid I don't have access to a different machine to test it on at the moment. The preRenderFBO doesn't crash (tried like 20 times), but doesn't draw anything - maybe it isn't supposed to. Valgrind didn't report anything out of the ordinary either. The postRenderNormal works fine. Using 64bit linux, OSG svn 9827, nvidia 8600M-GT, driver 180.29. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cull time doubled?
On Tue, Feb 10, 2009 at 2:19 AM, Pecoraro, Alexander N alexander.n.pecor...@lmco.com wrote: On the Enterprise Redhat Linux computer I have 4 64 bit dual core Xeon 3Ghz processors. On my Windows XP computer I have an Intel 64 bit Core2 DUO 2Ghz CPU. BTW, I found in the GCC documentation that if the gcc linker reports an undefined reference to __sync_add_and_fetch_4 then that means the built-in atomic functions are not supported on your processor. So my Linux computer must not support atomic built in functions It sure does, I believe everything from 486 up does. You might need to add a -march=native (or the specific equivalent) option to gcc, even though I only ever needed that with 32 bit code. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
On Fri, Feb 6, 2009 at 1:18 PM, Robert Osfield robert.osfi...@gmail.com wrote: Could you please try out the svn/trunk or OSG-2.8 branch to double check that the lwo plugin is now behaving itself. Hi Robert, Apparently both versions now load the model, thank you. There is only the original issue with multitexturing remaining, as reported by Marco in november. That mail thread seems to have died without ever receiving a reply from the author of the change causing the breakage (Bob). -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] -2.8 branch, testing-- vs71
On Fri, Feb 6, 2009 at 12:08 PM, Luigi Calori l.cal...@cineca.it wrote: I do not know if is my way of build or if is the static build, but I get link error in tiff plugin if I do not link also with jpeg and zip lib. Yes, that is normal with static tiff (even on linux). I have reported it here and on the cmake list but no solution yet. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
On Thu, Feb 5, 2009 at 4:34 PM, Robert Osfield robert.osfi...@gmail.com wrote: HI Csaba, I've just looked at the files, and the .osg file has 0 0 0's for all the vertices, looking at your code segment from the crash it kinda looks like the tex coords are derived from the vertex positions, so all 0 0 0's for vertices would map to lot's of divide by zeros and nans as a result. This would suggest either the original data is broken, or that the vertex reading is broken. Does this model load OK into lightwave? Could you post a screen shot? Don't know, I assume so. Blender loads it. I have tried some other models from different source and they don't work either. Simon reported it worked in 2.7.1, I just verified it worked in 2.7.4 too. I am now gonna build 2.7.8. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
On Thu, Feb 5, 2009 at 4:49 PM, Robert Osfield robert.osfi...@gmail.com wrote: I've just grabbed the source for lwo from 2.7.1 and applied it to OSG-2.8 and I get a different result from doing a conv to .osg but I still don't get a valid model - the tex coords are now all inf, rather nan. If 2.7.4 works for you could you send me the a working .osg so I can compare against. Hi Robert, I am now on 2.7.6, it works as well (except for the original multitexturing problem Marco reported on 6th November). Attached the .osg file. -- Csaba multitextured_cube.osg Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
On Thu, Feb 5, 2009 at 5:24 PM, Robert Osfield robert.osfi...@gmail.com wrote: Are you working on a 32 or 64bit system? I am on linux 64bit. Now I have verified with last night's 32 bit mingw build too, it gives a somewhat different, but equally bad, result (note, I didn't have the textures). Update on the build: 2.7.8 is broken, now building 2.7.7 -- Csaba multitextured_cube_mingw.osg Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
On Thu, Feb 5, 2009 at 5:44 PM, Csaba Halász csaba.hal...@gmail.com wrote: Update on the build: 2.7.8 is broken, now building 2.7.7 2.7.7 is fine. So the trouble is somewhere between 2.7.7 and 2.7.8 . Judging from the symptoms, It could be an unitialized variable. Now I have to leave for a couple of hours, but I'll make a valgrind run and continue the bisecting later. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
On Thu, Feb 5, 2009 at 6:11 PM, Robert Osfield robert.osfi...@gmail.com wrote: BTW, what OS/g++ version are you working on? debian, with a somewhat old g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) The mingw build is on 32bit windows xp, g++.exe (GCC TDM-2 for MinGW) 4.3.0 -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
On Thu, Feb 5, 2009 at 5:57 PM, Csaba Halász csaba.hal...@gmail.com wrote: Now I have to leave for a couple of hours, but I'll make a valgrind run and continue the bisecting later. Rev 9397 is the first non-working revision. Looks like a lot of int-long changes, which seems to agree with your 64 bit theory. Except it is broken on 32 bit too. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
On Thu, Feb 5, 2009 at 10:16 PM, Csaba Halász csaba.hal...@gmail.com wrote:
Rev 9397 is the first non-working revision. Looks like a lot of
int-long changes, which seems to agree with your 64 bit theory. Except
it is broken on 32 bit too.
LOL, it is one for Sukender's list :)
for(int i=0; i4; ++i)
{
*dest_ptr = *src_ptr;
}
Can you spot the error? :)
--
Csaba
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] LWO loading problem
Hi everybody.
I have gotten a report that the LWO loader doesn't seem to work.
Investigating, I grabbed the sample LWO file posted by Marco Jez back
in november last year (attached for convenience).
Loading into osgviewer, I get an empty view. Trying osgconv, I get an
osg file full of zeroes and nans (also attached).
With SIGFPE enabled, gdb shows:
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7f9b6be43730 (LWP 10599)]
0x7f9b6756e456 in lwosg::Block::setup_texture_point
(this=0xaee3c8, p...@0x7fff73fdcca0) at
OpenSceneGraph/src/osgPlugins/lwo/Block.cpp:141
141 Q.x() *= 1/imap_.mapping.size_.x();
Current language: auto; currently c++
(gdb) p imap_.mapping
$1 = {center_ = {_v = {0, 0, 0}}, size_ = {_v = {0, 0, 0}}, rotation_
= {_v = {0, 0, 0}},
csys_ = lwosg::Texture_mapping::OBJECT}
That's clearly the source of the nans but maybe not the root of the problem.
I haven't tried to find the exact svn rev this got broken yet, maybe
somebody has a quick solution right away.
--
Thanks,
Csaba
multitextured_cube.lwo
Description: Binary data
multitextured_cube.osg
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how can i get a MINGW based source code?
On Mon, Dec 29, 2008 at 9:55 AM, Andreas Goebel a-goe...@gmx.de wrote: Zhu liangxiong schrieb: hi my project need osg, and we use eclipse+QT+mingw. so i am not sure, whether i can compile the osg by mingw. and you guys know, please tell me ,and also how to. appreciate for any comment . You can. You need MSys, and set CMake to generate Makefiles for MSys/Mingw. Read the howto in the osg-wiki. I haven´t done so for some time, but it used to work without problems. It still does, as you can see on the dashboard: http://www.cdash.org/CDashPublic/index.php?project=OpenSceneGraph -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Thu, Nov 20, 2008 at 2:34 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: sparky Linux 2.4.21-102-smp x86_64 GNU/Linux My crash seems to be of this type, although no problem with threading model switching. I wonder if I can try to use software rendering to see if it makes a difference. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Thu, Nov 20, 2008 at 3:51 PM, Csaba Halász [EMAIL PROTECTED] wrote: I wonder if I can try to use software rendering to see if it makes a difference. I have run it with mesa in a nested x server, no hangs. After each added view, however, I got a single Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) message (ie. *not* every frame). Don't know if that is relevant. Also, the software rendering might be too slow to produce the problem. Anybody got some further suggestions? -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Thu, Nov 20, 2008 at 8:12 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: When it hung, I had just created a 4th view (=4th context). Uncoincidentally, there are 4 threads on GraphicsThread::run(), which calls GraphicsContext::makeCurrent(), which calls GraphicsWindowWin32::makeCurrentImplementation, which is stuck on the wglMakeCurrent() call. One of those 4 is stuck in the middle of the graphics driver DLL, but I'm not sure that's relevant. Yes, exactly the same for me. And I am on linux. I wondered if simply calling cancel() on the threads is a good idea. I'd feel a lot better if the threads would check for an exit flag at a well-defined place. Could it be possible that one of the threads is inside the gl lib doing something and then it gets abruptly cancelled without releasing some critical resource? Of course the gl lib should make sure cancellation is disabled while inside such code, but who knows. Assuming a resource is left locked could explain why the makeCurrent is blocked - it might be (busy-)waiting on that very resource. Also, I have added a join() call after the cancel in GraphicsContext.cpp and Camera.cpp, that have the strange effect of completely locking up X and not just the test app. Robert's changed version doesn't seem to make a difference here. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Thu, Nov 20, 2008 at 4:50 PM, Csaba Halász [EMAIL PROTECTED] wrote: On Thu, Nov 20, 2008 at 3:51 PM, Csaba Halász [EMAIL PROTECTED] wrote: I wonder if I can try to use software rendering to see if it makes a difference. I have run it with mesa in a nested x server, no hangs. After each added view, however, I got a single Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) message (ie. *not* every frame). Don't know if that is relevant. Also, the software rendering might be too slow to produce the problem. Anybody got some further suggestions? I think the intel driver is entirely open-source, can somebody try with that? That should at least point to where the rogue thread is spinning. Assuming it exhibits the same behaviour. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Wed, Nov 19, 2008 at 10:42 PM, Don Leich [EMAIL PROTECTED] wrote: pthread_cond_wait, FP=7fbfffd5a0 pthread_cond_wait, FP=7fbfffd5b0 OpenThreads::Condition::wait, FP=7fbfffd610 OpenThreads::BlockCount::block, FP=7fbfffd660 osgViewer::ViewerBase::renderingTraversals, FP=7fbfffd870 osgViewer::ViewerBase::frame, FP=7fbfffd8a0 osgViewer::ViewerBase::run,FP=7fbfffd8d0 osgViewer::CompositeViewer::run, FP=7fbfffd920 main, FP=7fbfffdc60 __libc_start_main, FP=7fbfffdd30 _start,FP=7fbfffdd40 I had a recent submission affecting this part of the code. I have locally reverted that and I still see the hang so it is not likely to be the cause. Nevertheless, you could try for yourselves. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi people, my call stacks show that all the waiting is going on because one of the threads is stuck in makeCurrent: #0 0x7f34b8b7a727 in sched_yield () from /lib/libc.so.6 #1 0x7f34b8385665 in ?? () from /usr/lib/libGLcore.so.1 #2 0x7f34b80a0d8a in ?? () from /usr/lib/libGLcore.so.1 #3 0x7f34b994f056 in ?? () from /usr/lib/libGL.so.1 #4 0x7f34b995386b in ?? () from /usr/lib/libGL.so.1 #5 0x7f34bb641843 in osgViewer::GraphicsWindowX11::makeCurrentImplementation (this=0x11930d0) at /home/hcs/src/OpenSceneGraph/src/osgViewer/GraphicsWindowX11.cpp:804 #6 0x7f34ba21013c in osg::GraphicsContext::makeCurrent (this=0x11930d0) at /home/hcs/src/OpenSceneGraph/src/osg/GraphicsContext.cpp:512 #7 0x7f34ba21b4b6 in osg::GraphicsThread::run (this=0x7f34b01e7ef0) at /home/hcs/src/OpenSceneGraph/src/osg/GraphicsThread.cpp:33 #8 0x7f34b9cd0f9c in OpenThreads::ThreadPrivateActions::StartThread (data=0x7f34b01e7f08) at /home/hcs/src/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:172 #9 0x7f34b9ab73f7 in start_thread () from /lib/libpthread.so.0 #10 0x7f34b8b9397d in clone () from /lib/libc.so.6 #11 0x in ?? () And it isn't a proper deadlock, more like a busy wait (single thread is running at 100% cpu) For the record, I am on linux, nvidia driver 177.80. I wonder if any ATI users are seeing this? -- Hope this helps, Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Introducing osgmemorytest
On Tue, Nov 11, 2008 at 7:01 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I probably won't be the only one to say it but... This is wicked awesome. :) It is *wicked* all right ... Notebook, Intel c2d 2.2Ghz, 3GB ram + 4GB swap, nVidia 8600M-GT 256MB, driver 177.80 1) 103 2) 207 3) 154 seconds, 6GB (!) memory 4) 6.79 seconds 5) 2.58 seconds 6) 2.16 seconds 7) 215 8) lockup, second try: 237 9) 239, used up all 7GB memory, lockup -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] A Windows binary version of OSG 2.6.x available?
On Fri, Nov 7, 2008 at 10:55 AM, Robert Osfield [EMAIL PROTECTED] wrote: You can uploaded data to the server via WebDAV: I wonder if there is public interest in having the automated nightly builds available. -- Csaba (aka. Jester on the dashboard) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to texture problem
On Thu, Nov 6, 2008 at 5:16 PM, Engvall Åsa [EMAIL PROTECTED] wrote: I want to render the scene to a texture and use the texture in a shader. The texture image is saved to file by a postdraw callback, so I can look at it. I'm doing something wrong because the texture becomes all gray. I have the same problem. To make things worse, I have modified the osgdistortion example and that works. Unfortunately I was unable to pinpoint the difference between my application and the working example. I hope maybe somebody can list known caveats/requirements to using image attach. FWIW, it works if I don't attach the image, and use readPixels in a final draw callback. But I assume that is suboptimal (it does cause significant increase in the draw times). -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] deadlock loading io plugin?
On Mon, Nov 3, 2008 at 5:08 PM, Max Pfingsthorn [EMAIL PROTECTED] wrote: I'm using the current trunk of OSG (updated 30 mins ago) on Ubuntu 8.04. The program hangs on the line with osgDB::readNodeFiles. I have no idea why. This is what GDB says: #6 0xb7ea30c1 in OpenThreads::ReentrantMutex::lock () from /usr/local/OpenSceneGraph/lib/libosg.so.50 Works here. As the call stack shows a ReentrantMutex, the thread can not deadlock on itself. Thus, another thread must be involved. Please check call stacks for all threads. Also, if you have debugging symbols, you could check the _threadHoldingMutex member of the ReentrantMutex to see who is the owner. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] deadlock loading io plugin?
On Mon, Nov 3, 2008 at 6:12 PM, Robert Osfield [EMAIL PROTECTED] wrote: If this all fails then it looks like there is a bug in ReentrantMutex. Hmm, looking at it, I wonder why the thread checking is disabled in the unlock path? Is it for performance reasons? (couldn't find the relevant svn comment) Don't think this could cause deadlock, rather quite the opposite. Also, is the _lockCountMutex at all necessary? At first glance the _lockCount value is only ever modified from the owner thread and that can not cause problems. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] mingw build problems
On Thu, Oct 30, 2008 at 9:38 AM, Alberto Luaces [EMAIL PROTECTED] wrote: Hi Csaba, Out of curiosity, are you jester? Hi Alberto, Yes that's me :) If that were your machine, how did you manage to install Dart with Mingw? I am be interested in doing the same with a Cygwin build. I built tcl and installed Dart. But it didn't work properly, and later I found out you *don't* need dart/tcl at all. Current cmake has a ctest module that does everything. Somebody should put this in big fat letters somewhere :) So just enable the dart stuff in the config and you are done. (It will still use DartConfiguration.tcl, don't be surprised by that) -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] mingw build problems
Hi! I encountered some problems while building OSG using mingw. 1) can't build osgwrappers. on 32 bit windows, ld goes up to about 2GB mem usage and then aborts. Cross-compiling on 64 bit linux, it went up to a whopping 5GB after 10 minutes, at which point I had to kill it as I only have 3GB ram and it was swapping like crazy. I might try to abuse one of our servers with 16GB ram later, just to see whether it finishes eventually :) PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 22624 hcs 20 0 5472m 2.8g 540 D 11 93.8 10:00.29 ld $ /usr/i586-mingw32msvc/bin/ld --version GNU ld (GNU Binutils) 2.18.50.20080109 Native linux builds fine (uses about 800MB) 2) None of the OPENTHREADS_ATOMIC_USE flags work. I assume either gcc or win32 interlocked would be the right choice. As I am using gcc, I went for the GCC builtins first, but I get errors: CMakeFiles/OpenThreads.dir/__/common/Atomic.cpp.obj:Atomic.cpp:(.text+0x3b): undefined reference to `___sync_bool_compare_and_swap_4' CMakeFiles/OpenThreads.dir/__/common/Atomic.cpp.obj:Atomic.cpp:(.text+0xa5): undefined reference to `___sync_sub_and_fetch_4' CMakeFiles/OpenThreads.dir/__/common/Atomic.cpp.obj:Atomic.cpp:(.text+0xc5): undefined reference to `___sync_add_and_fetch_4' CMakeFiles/OpenThreads.dir/__/common/Atomic.cpp.obj:Atomic.cpp:(.text+0x61): undefined reference to `___sync_fetch_and_xor_4' CMakeFiles/OpenThreads.dir/__/common/Atomic.cpp.obj:Atomic.cpp:(.text+0x71): undefined reference to `___sync_fetch_and_or_4' CMakeFiles/OpenThreads.dir/__/common/Atomic.cpp.obj:Atomic.cpp:(.text+0x81): undefined reference to `___sync_fetch_and_and_4' collect2: ld returned 1 exit status make[2]: *** [bin/libOpenThreads.dll] Error 1 The single thing I found using google about this was that gcc seems to think these intrisics are not supported. Next I tried win32 interlocked, but apparently that relies on msvc instrinics: OpenThreads/common/Atomic.cpp:18:20: error: intrin.h: No such file or directory OpenThreads/common/Atomic.cpp: In member function 'unsigned int OpenThreads::Atomic::operator++()': OpenThreads/common/Atomic.cpp:46: error: invalid conversion from 'volatile long int*' to 'long int*' OpenThreads/common/Atomic.cpp:46: error: initializing argument 1 of 'LONG InterlockedIncrement(long int*)' OpenThreads/common/Atomic.cpp: In member function 'unsigned int OpenThreads::Atomic::operator--()': OpenThreads/common/Atomic.cpp:60: error: invalid conversion from 'volatile long int*' to 'long int*' OpenThreads/common/Atomic.cpp:60: error: initializing argument 1 of 'LONG InterlockedDecrement(long int*)' OpenThreads/common/Atomic.cpp: In member function 'unsigned int OpenThreads::Atomic::AND(unsigned int)': OpenThreads/common/Atomic.cpp:74: error: '_InterlockedAnd' was not declared in this scope OpenThreads/common/Atomic.cpp: In member function 'unsigned int OpenThreads::Atomic::OR(unsigned int)': OpenThreads/common/Atomic.cpp:88: error: '_InterlockedOr' was not declared in this scope OpenThreads/common/Atomic.cpp: In member function 'unsigned int OpenThreads::Atomic::XOR(unsigned int)': OpenThreads/common/Atomic.cpp:102: error: '_InterlockedXor' was not declared in this scope OpenThreads/common/Atomic.cpp: In member function 'unsigned int OpenThreads::Atomic::exchange(unsigned int)': OpenThreads/common/Atomic.cpp:117: error: invalid conversion from 'volatile long int*' to 'long int*' OpenThreads/common/Atomic.cpp:117: error: initializing argument 1 of 'LONG InterlockedExchange(long int*, LONG)' OpenThreads/common/Atomic.cpp: In member function 'OpenThreads::Atomic::operator unsigned int() const': OpenThreads/common/Atomic.cpp:132: error: 'MemoryBarrier' was not declared in this scope OpenThreads/common/Atomic.cpp:133: error: invalid static_cast from type 'const volatile long int' to type 'const volatile unsigned int' OpenThreads/common/Atomic.cpp: In member function 'void* OpenThreads::AtomicPtr::get() const': OpenThreads/common/Atomic.cpp:163: error: 'MemoryBarrier' was not declared in this scope make[2]: *** [src/OpenThreads/win32/CMakeFiles/OpenThreads.dir/__/common/Atomic.cpp.obj] Error 1 make[1]: *** [src/OpenThreads/win32/CMakeFiles/OpenThreads.dir/all] Error 2 make: *** [all] Error 2 (msdn says these come from winbase.h, so I removed the intrin.h reference, but still no luck) Note, I get a working OSG with the fall-back implementation, but I assume that is suboptimal in terms of performance. 3) the libtiff I use (version 3.8.2) depends on libjpeg and zlib (just like libpng depends on zlib). Cmake doesn't handle this. How can I pass this information to the build process? -- Thanks, Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] mingw build problems
On Wed, Oct 29, 2008 at 9:05 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Csaba, 2) None of the OPENTHREADS_ATOMIC_USE flags work. I assume either gcc or win32 interlocked would be the right choice. As I am using gcc, I went for the GCC builtins first, but I get errors: Matthias will give you the complete answer, but I think the gcc builtins need a recent gcc (4.x+), whereas I think MinGW is stuck at gcc 3.x... Hi J-S, I have a recent gcc: $ i586-mingw32msvc-gcc --version i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2) And for the win32 interlocked, you need to be compiling with VC++ (which you can do with makefiles by calling cc.exe, but the CMake generated makefiles for MinGW surely use gcc only, so it won't be an option for you). Yeah, that's what I figured too. So I guess I have to get the gcc builtins to work if possible. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] mingw build problems
On Wed, Oct 29, 2008 at 11:15 PM, Csaba Halász [EMAIL PROTECTED] wrote: Yeah, that's what I figured too. So I guess I have to get the gcc builtins to work if possible. Ok, you can strike this from the list. I used -DCMAKE_CXX_FLAGS_RELEASE=-O2 -march=i686 and that just got added as a variable but did not get used. Apparently I have to specify it is a STRING, so -DCMAKE_CXX_FLAGS_RELEASE:STRING=-O2 -march=i686 works fine. For the tiff issue, I have compiled a libtiff without jpeg or zlib support, but that isn't really an acceptable solution. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] mingw build problems
Have run into another trouble, I had to add OSGSHADOW_EXPORT to each of the embedded protected ViewData struct's in the osgShadow lib, otherwise I get linking errors with the osgshadow example. If it doesn't break other platforms, can they be added in svn? -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for feedback : AC3D loader behavior w.r.t texture repeat and clamping
On Mon, Oct 27, 2008 at 10:42 PM, John Cummings [EMAIL PROTECTED] wrote: FYI, here is the link to the discussion on the Ac3D forum: http://www.inivis.com/forum/showthread.php?t=5090 It seems to be headed in the same direction as Robert's comments regarding keeping track of the UV ranges. Which, unfortunately, would still break our app (flightgear), as we have default texture coordinates within the 0,1 range, but later we change those dynamically and assume texture repeat. Of course we could work around that ourselves if absolutely necessary. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Flightgear-devel] OT, real life: my first turboprop
On Thu, Oct 23, 2008 at 12:25 PM, Torsten Dreyer [EMAIL PROTECTED] wrote: Sorry for the long posting Apology accepted :) Nice report, thanks for sharing. Have you figured out what was wrong with the autopilot? -- Csaba/Jester ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] possible threading-related crash with on-screen stats
On Mon, Oct 20, 2008 at 10:12 AM, Robert Osfield [EMAIL PROTECTED] wrote: HI Csaba, Are you working on the SVN version of the OSG? As the new StatsHandler additions aren't thread safe yet - I've also seen crashes when bringing up the scene graph statistics, although not any OpenGL error report. Hi Robert, Ok, then it is a known issue. FYI, the DrawSerialization was added to improve performance when running multi-threaded, counter-intuitive it may that be... but driver/hardware limitations on the PC's with 2 graphics cards + 2 (or 4) outputs I've tested all have show better performance when running with the draw threads serialized. Interesting, I'll see what report I get from the fellow who did this: http://www.youtube.com/watch?v=brG3-yyvv9Q (and now plans to go for 8 gpus) Btw, have you seen my other mail in the infinite block with CullThreadPerCameraDrawThreadPerContext topic? -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] AC3D Texture clamping
On Mon, Oct 20, 2008 at 8:50 AM, Mathias Fröhlich [EMAIL PROTECTED] wrote: With the lack of an ac3d modeller here, can you tell me how it looks like in ac3d, when texrep is * omitted * set to 0 0 Is there a way to get non repeating textures in ac3d? I don't personally have ac3d either, so I asked other people :) When texrep is omitted, it defaults to texrep 1 1 as per the spec, and that means texture *is* repeated, according to the texture coordinates. Also, when texrep is set to 1 1 in the gui, upon saving the texrep attribute is omitted. Using texrep 0 0 scales the texture coordinates to 0, 0 so the whole area is filled with the corner texel (this seems to work same in osg) We couldn't come up with a way to produce clamped textures in ac3d. -- Thanks for looking into this. Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] infinite block with CullThreadPerCameraDrawThreadPerContext
On Thu, Oct 16, 2008 at 2:42 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
HI Csaba,
I suspect the particular problem you are seeing is not directly driver
related, but is an OSG bug, differences in drivers might change the
timing slightly which leads to the problem not becoming visible, but
may well still be lurking.
Hi Robert,
Huh, took me two days, but I think I have traced this to a race condition.
Apparently the _endDynamicDrawBlock was already reached by a graphics
thread before the viewer got a chance to reset it.
So then that draw thread was released (and subsequently blocked on the
sceneview queue) and the viewer has gone to infinite wait on the
_endDynamicDrawBlock later.
This simpe patch (that doesn't even hint at how difficult it is to
trace such bugs) seems to fix the issue here:
Index: src/osgViewer/ViewerBase.cpp
===
--- src/osgViewer/ViewerBase.cpp(revision 9034)
+++ src/osgViewer/ViewerBase.cpp(working copy)
@@ -674,14 +674,14 @@
bool doneMakeCurrentInThisThread = false;
-// dispatch the the rendering threads
-if (_startRenderingBarrier.valid()) _startRenderingBarrier-block();
-
if (_endDynamicDrawBlock.valid())
{
_endDynamicDrawBlock-reset();
}
+// dispatch the the rendering threads
+if (_startRenderingBarrier.valid()) _startRenderingBarrier-block();
+
// reset any double buffer graphics objects
for(Cameras::iterator camItr = cameras.begin();
camItr != cameras.end();
I am not even sure why the _endDynamicDrawBlock has to be reset. Comments?
--
Csaba
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] is it possible to compile osg with mingw?
On Thu, Oct 16, 2008 at 10:07 AM, Michal Turlik [EMAIL PROTECTED] wrote: Hi, I am trying to compile osg with mingw. After have compiled the cmake I obtein a message stating the M$ VS 6 is required. Yes, I have it working. Not sure what message you get and where. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] infinite block with CullThreadPerCameraDrawThreadPerContext
On Thu, Oct 16, 2008 at 2:42 PM, Robert Osfield [EMAIL PROTECTED] wrote: CullThreadPerCameraDrawThreadPerContext is the most complex of all the osgViewer threading models, and with it the widest range of different thread/barrier combinations. It could be that you are using a combination of cameras/contexts that hasn't been tested before, or simply that the timing of threads in your case breaks the setup. Without being able to reproduce the problem at my end there isn't too much I can do to help out debug it. Could you have a bash at recreating the problem with an existing OSG example such as osgcamera or osgwindows? I can bash all I want, those work :) My investigation seems to indicate that draw() is called twice for a camera: Start frame3 cull() for camera GUI 0xf15aa0 cull() for camera GUI 0xf15aa0 got SceneView 0xf12c00 cull() for camera unnamed1 0xf15fd0 cull() for camera unnamed1 0xf15fd0 got SceneView 0xf1aa50 cull() for camera GUI 0xf15aa0 done for SceneView 0xf12c00 end cull() for camera GUI 0xf15aa0 _clampProjectionMatrix not applied, invalid depth range, znear = 3.40282e+38 zfar = -3.40282e+38 cull() for camera unnamed1 0xf15fd0 done for SceneView 0xf1aa50 end cull() for camera unnamed1 0xf15fd0 draw() for camera unnamed1 0xf15fd0 draw() for camera unnamed1 0xf15fd0 got SceneView 0xf1aa50 glGetString(GL_RENDERER)==GeForce 8600M GT/PCI/SSE2 draw() for camera unnamed1 0xf15fd0 done for SceneView 0xf1aa50 end draw() for camera unnamed1 0xf15fd0 draw() for camera GUI 0xf15aa0 draw() for camera GUI 0xf15aa0 got SceneView 0xf12c00 draw() for camera GUI 0xf15aa0 done for SceneView 0xf12c00 end draw() for camera GUI 0xf15aa0 draw() for camera unnamed1 0xf15fd0 Huh, unnamed1 was already drawn during this frame. I guess that is not normal? I will try to get a backtrace now. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads/pthreads OpenMP on RHEL5.2
On Wed, Oct 15, 2008 at 5:46 PM, Robert Osfield [EMAIL PROTECTED] wrote: numProcessors = 4 cpunum=1 cpunum=2 cpunum=3 cpunum=0 running and setting thread 0x737238 for cpunum=3 running and setting thread 0x737638 for cpunum=0 running and setting thread 0x734bf8 for cpunum=1 running and setting thread 0x736de8 for cpunum=2 So all looks correct in terms of num of processors and cpu number assigned for affinity. I wonder why OSG assigns threads to cpus by itself and not rely on the operating system. Or at least have a switch to disable this behaviour. Suppose I have 3 cameras and 2 contexts, that could mean 5 threads each with different cpu needs. How does OSG know what threads to put on the same cpu? All I see is a simple round-robin distribution. Am I missing something? Is this affinity possibly just a hint rather than an enforced constraint, so threads might run on other cpus too? -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads/pthreads OpenMP on RHEL5.2
On Wed, Oct 15, 2008 at 6:15 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Csaba, On Wed, Oct 15, 2008 at 5:07 PM, Csaba Halász [EMAIL PROTECTED] wrote: So all looks correct in terms of num of processors and cpu number assigned for affinity. I wonder why OSG assigns threads to cpus by itself and not rely on the operating system. Because a OS will let that thread move from core to core and destroy cache coherency and with it most or sometimes all the performance benefit of going multi-threaded. Setting thread affinity is *crucial* to getting good multi-threaded performance. But if OSG happens to force 2 cpu intensive threads to the same core, performance will suffer anyway, and more than a simple cache efficiency issue. I have 3 cameras, two of which are using the same graph and a third that's drawing GUI elements. As such this third one is much less cpu intensive. So depending on what order they get instantiated the two main cameras might end up on the same cpu while the other cpu is bored to death with the GUI camera. (I have dual-core machine) As a related question, in the stats display if multiple cpus are used properly, should that manifest itself as overlapping bars? Because I don't see any such, the different phases (draw, cull) for the cameras all appear to be run after each other. I am now building osg with your debug modifications, to see if that tells me something. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads/pthreads OpenMP on RHEL5.2
On Wed, Oct 15, 2008 at 6:47 PM, Robert Osfield [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2008 at 5:30 PM, Csaba Halász [EMAIL PROTECTED] wrote: As a related question, in the stats display if multiple cpus are used properly, should that manifest itself as overlapping bars? Because I don't see any such, the different phases (draw, cull) for the cameras all appear to be run after each other. I am now building osg with your debug modifications, to see if that tells me something. On my quad core system I certain do see overlap. Milage will vary across hardware, OS and OSG usage. Here is what stats I get: http://imagebin.ca/view/lDtnJ9ET.html I have tried your debugging mods, with the osgcamera example I get the expected printout: numProcessors = 2 cpunum=1 cpunum=0 cpunum=1 running and setting thread 0xd91d18 for cpunum=0 running and setting thread 0xcb31c8 for cpunum=1 running and setting thread 0xd1e528 for cpunum=1 With our app (flightgear), however, I don't get any. I might have messed up the compilation, but do you think there is another code path to set threading model that could circumvent your prints? In the meantime, I'll investigate too. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads/pthreads OpenMP on RHEL5.2
On Wed, Oct 15, 2008 at 7:07 PM, Robert Osfield [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2008 at 6:01 PM, Csaba Halász [EMAIL PROTECTED] wrote: Here is what stats I get: http://imagebin.ca/view/lDtnJ9ET.html I have tried your debugging mods, with the osgcamera example I get the expected printout: With our app (flightgear), however, I don't get any. I might have messed up the compilation, but do you think there is another code path to set threading model that could circumvent your prints? In the meantime, I'll investigate too. I don't know anything about flight gear code I'm afraid. There is only one method in ViewerBase that sets up threading so it should be called your method if flight gear is linking your app and set up threading the normal way. As you can see on the screenshot, the statistics show that the threading model is set, but no printout and the bars don't overlap either. The threading is set like so: viewer = new osgViewer::Viewer; viewer-setThreadingModel(osgViewer::Viewer::CullThreadPerCameraDrawThreadPerContext); It seems to be loading the freshly compiled osg libs (fails to start if I rename them) We also use a databasepager, that seems to run on a different thread as expected. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads/pthreads OpenMP on RHEL5.2
On Wed, Oct 15, 2008 at 8:28 PM, Robert Osfield [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2008 at 6:45 PM, Csaba Halász [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2008 at 7:23 PM, Csaba Halász [EMAIL PROTECTED] wrote: The threading is set like so: viewer = new osgViewer::Viewer; viewer-setThreadingModel(osgViewer::Viewer::CullThreadPerCameraDrawThreadPerContext); And that's exactly the problem ... setting the threading mode before the viewer is realized does not start threading. I added an explicit call to startThreading() later, and get the printouts now :) This sounds like a bug in osgViewer, it shouldn't matter which order your set the threading model. Hmm, upon closer look Viewer::realize() does call setUpThreading() which in turn calls startThreading(). Gotta do some debugging why it doesn't work for me. Has the stats graph changed at all? Yes, I now have overlapping bars. Unfortunately our code is doing something from the wrong thread, so CullThreadPerCameraDrawThreadPerContext doesn't work yet and even CullDrawThreadPerContext crashes after some time. But these problems are likely our fault. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads/pthreads OpenMP on RHEL5.2
On Wed, Oct 15, 2008 at 8:44 PM, Csaba Halász [EMAIL PROTECTED] wrote:
On Wed, Oct 15, 2008 at 8:28 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
This sounds like a bug in osgViewer, it shouldn't matter which order
your set the threading model.
Hmm, upon closer look Viewer::realize() does call setUpThreading()
which in turn calls startThreading().
Gotta do some debugging why it doesn't work for me.
Got it:
int ViewerBase::run()
{
if (!isRealized())
{
realize();
}
But the isRealized() function doesn't really say if realize() has been
called or not, it just checks if *any* of the gc's are realized. Our
code happened to call realize on the gc, so the viewer's realize()
never got called. Depending on whether it is allowed to realize gc's
manually it is either a bug or not :)
--
Csaba
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] infinite block with CullThreadPerCameraDrawThreadPerContext
Hi again, Now that I got threading running, I have run into this trouble: draw() 0xee0b20 draw() got SceneView 0xf18a80 end draw() 0xee0b20 draw() 0xda1f80 cull() cull() got SceneView 0xf03e90 end cull() 0xee0b20 cull() cull() got SceneView 0xf7b020 _clampProjectionMatrix not applied, invalid depth range, znear = 3.40282e+38 zfar = -3.40282e+38 end cull() 0xda1f80 draw() got SceneView 0xf7b020 end draw() 0xda1f80 draw() 0xee0b20 draw() got SceneView 0xf03e90 end draw() 0xee0b20 draw() 0xda1f80 cull() cull() got SceneView 0xf84a20 _clampProjectionMatrix not applied, invalid depth range, znear = 3.40282e+38 zfar = -3.40282e+38 end cull() 0xda1f80 draw() got SceneView 0xf84a20 cull() cull() got SceneView 0xf18a80 end cull() 0xee0b20 end draw() 0xda1f80 draw() 0xee0b20 draw() got SceneView 0xf18a80 end draw() 0xee0b20 draw() 0xda1f80 It stops here. (gdb) thr 5 [Switching to thread 5 (Thread 0x420a5950 (LWP 28584))]#0 0x2ae3f4c89b99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x2ae3f4c89b99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x2ae3f7a55c56 in OpenThreads::Condition::wait (this=value optimized out, mutex=value optimized out) at /home/hcs/src/OpenSceneGraph/src/OpenThreads/pthreads/PThreadCondition.c++:137 #2 0x2ae3f68d0bd3 in osgViewer::Renderer::TheadSafeQueue::takeFront (this=0x10f8a78) at /home/hcs/src/OpenSceneGraph/include/OpenThreads/Block:42 #3 0x2ae3f68d25de in osgViewer::Renderer::draw (this=0x10f8980) at /home/hcs/src/OpenSceneGraph/src/osgViewer/Renderer.cpp:340 #4 0x2ae3f772eac4 in osg::GraphicsContext::runOperations (this=0x10f99a0) at /home/hcs/src/OpenSceneGraph/src/osg/GraphicsContext.cpp:688 #5 0x2ae3f776c688 in osg::OperationThread::run (this=0x11cd6c0) at /home/hcs/src/OpenSceneGraph/src/osg/OperationThread.cpp:413 #6 0x2ae3f77351c0 in osg::GraphicsThread::run (this=0x11cd6c0) at /home/hcs/src/OpenSceneGraph/src/osg/GraphicsThread.cpp:38 #7 0x2ae3f7a55537 in OpenThreads::ThreadPrivateActions::StartThread (data=value optimized out) at /home/hcs/src/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:172 #8 0x2ae3f4c853f7 in start_thread () from /lib/libpthread.so.0 #9 0x2ae3f839497d in clone () from /lib/libc.so.6 #10 0x in ?? () Any ideas? -- Thanks, Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reporting Builds
On Thu, Oct 16, 2008 at 1:23 AM, Csaba Halász [EMAIL PROTECTED] wrote: I also tried a mingw build, that seems to work too but the submission doesn't: Comparing with the linux makefile, I spotted this difference: CMakeFiles/NightlySubmit: /C/msys/home/hcs/tcl-inst/bin/tclsh.exe C:/msys/home/hcs/Dart/Source/Client/DashboardManager.tcl C:/msys/home/hcs/OSG-build-nightly/DartConfiguration.tcl Nightly Submit -vs- CMakeFiles/NightlySubmit: CMakeFiles/NightlySubmit.dir/build.make /usr/bin/ctest -D NightlySubmit I have ctest installed on mingw too, and cmake finds it as well: //Path to ctest program executable. CMAKE_CTEST_COMMAND:INTERNAL=C:/msys/home/hcs/cmake-inst/bin/ctest.exe Maybe I am missing something else that causes cmake to use the tcl submit (and that doesn't seem to support http) -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reporting Builds
On Thu, Oct 16, 2008 at 2:40 AM, Csaba Halász [EMAIL PROTECTED] wrote: Maybe I am missing something else that causes cmake to use the tcl submit (and that doesn't seem to support http) /o\ so I don't even need the dart thing, ctest can do everything? Where do I change the build name? In cmake I only see SITE, and the dartconfig might get regenerated? -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
On Tue, Oct 7, 2008 at 9:14 PM, Paul Melis [EMAIL PROTECTED] wrote: I seem to be getting some lock up when switching threading models in osgviewer (with the cow). However I also see these in 2.6.0 now that I test it (haven't been using 2.6 yet). What's more, switching of the threading model with 'm' does not always seem to happen. Sometimes when I press 'm' the threading model doesn't change, only when I press 'm' again. This is with vsync off, b.t.w., in case timings issues might be at play here. The lockup always seems to occur when switching to CullThreadPerCameraDrawThreadPerContext. Here's a relevant stack trace #0 0xe424 in __kernel_vsyscall () #1 0xb7963576 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7ef79c8 in OpenThreads::Condition::wait () from /home/melis/c/osg/build/2.7.2/bin/../lib/libOpenThreads.so.11 #3 0xb7a49e4d in osgViewer::ViewerBase::renderingTraversals () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #4 0xb7a48833 in osgViewer::ViewerBase::frame () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #5 0xb7a48971 in osgViewer::ViewerBase::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #6 0xb7a3a033 in osgViewer::Viewer::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #7 0x0804b1e6 in main () I can reproduce this as well. gcc 4.1.2, nvidia 8600M-GT 256MB, c2d 2.2GHz, driver 169.12, single display (laptop) 1920x1200. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
On Tue, Oct 7, 2008 at 10:58 PM, Paul Melis [EMAIL PROTECTED] wrote: Well, going back to 169.12 does seem to make that problem go away Interesting, since I have the problem with the 169.12 driver. Maybe I should upgrade to make it go away ;) -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Tue, May 27, 2008 at 12:08 PM, Tim Moore [EMAIL PROTECTED] wrote: Indeed. I've made the necessary changes to FlightGear, and it seems to be working fine. Except for being a cpu hog. Apparently, the pager thread is not blocked properly and continuously spins. The fact that the queue is empty is confirmed by the debug messages printed after the block call: HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0 I have been trying to find the place where the blocking is re-established when the queue goes empty, but could not find it. So I added an updateBlock() call at the end of DatabasePager::RequestQueue::takeFirst that seems to fix the issue. Could have added the call within the if-block, but this has the additional benefit of stopping runaway loops should somehow the pager thread get woken up without work to do. Index: DatabasePager.cpp === --- DatabasePager.cpp (revision 8398) +++ DatabasePager.cpp (working copy) @@ -273,6 +273,7 @@ databaseRequest = _requestList.front(); _requestList.erase(_requestList.begin()); } +updateBlock(); } I am not sure if I need an osg-submissions mail for this? -- Cheers, Csaba/Jester ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Tue, Jun 3, 2008 at 4:48 PM, Robert Osfield [EMAIL PROTECTED] wrote: Could you do an svn update on the OSG and let know if things are no work fine at your end, It works, thanks. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
