[osg-users] how to disable FBO extension

2009-12-19 Thread Csaba Halász
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

2009-03-20 Thread Csaba Halász
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

2009-03-13 Thread Csaba Halász
On Fri, Mar 13, 2009 at 11:16 AM, Robert Osfield
 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="

Re: [osg-users] division by zero in osgParticle/FluidProgram.cpp

2009-03-12 Thread Csaba Halász
On Thu, Mar 12, 2009 at 6:03 PM, Robert Osfield
 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] division by zero in osgParticle/FluidProgram.cpp

2009-03-12 Thread Csaba Halász
On Thu, Mar 12, 2009 at 5:04 PM, Tomlinson, Gordon
 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

2009-03-12 Thread Csaba Halász
On Thu, Mar 5, 2009 at 4:16 AM, Csaba Halász  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] [osgPlugins] fonts

2009-03-09 Thread Csaba Halász
On Mon, Mar 9, 2009 at 7:23 PM, Paul Shabash  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

2009-03-05 Thread Csaba Halász
Hi!

More division by zero trouble, this time in
include/osgDB/DatabasePager line 331:
double getAverageTimeToMergeTiles() const { return
_totalTimeToMergeTiles/static_cast(_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

2009-03-04 Thread Csaba Halász
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

2009-03-03 Thread Csaba Halász
On Mon, Mar 2, 2009 at 6:33 PM, Kim C Bale  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?

2009-02-09 Thread Csaba Halász
On Tue, Feb 10, 2009 at 2:19 AM, Pecoraro, Alexander N
 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] -2.8 branch, testing-- vs71

2009-02-06 Thread Csaba Halász
On Fri, Feb 6, 2009 at 12:08 PM, Luigi Calori  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] CDash questions

2009-02-06 Thread Csaba Halász
On Fri, Feb 6, 2009 at 2:49 PM, Jean-Sébastien Guay
 wrote:
>
> From what I've seen in the past few days (since I started submitting builds
> myself) they're removed from the list every night automatically. As you can
> see Sukender's Experimental builds from yesterday are not there anymore and
> I personally haven't found out how to remove an entry, so I deduce that
> they're removed automatically each night.

No, they aren't really removed, of course. The default page only shows
the entries for the current day, but all entries can be accessed via
the menu (calendar-previous-current-next).

-- 
Csaba (aka. Jester)
___
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

2009-02-06 Thread Csaba Halász
On Fri, Feb 6, 2009 at 1:18 PM, Robert Osfield  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] LWO loading problem

2009-02-05 Thread Csaba Halász
On Thu, Feb 5, 2009 at 10:16 PM, Csaba Halász  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; i<4; ++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


Re: [osg-users] LWO loading problem

2009-02-05 Thread Csaba Halász
On Thu, Feb 5, 2009 at 5:57 PM, Csaba Halász  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

2009-02-05 Thread Csaba Halász
On Thu, Feb 5, 2009 at 6:11 PM, Robert Osfield  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

2009-02-05 Thread Csaba Halász
On Thu, Feb 5, 2009 at 5:44 PM, Csaba Halász  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

2009-02-05 Thread Csaba Halász
On Thu, Feb 5, 2009 at 5:24 PM, Robert Osfield  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

2009-02-05 Thread Csaba Halász
On Thu, Feb 5, 2009 at 4:49 PM, Robert Osfield  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

2009-02-05 Thread Csaba Halász
On Thu, Feb 5, 2009 at 4:34 PM, Robert Osfield  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


[osg-users] LWO loading problem

2009-02-04 Thread Csaba Halász
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?

2009-01-04 Thread Csaba Halász
On Mon, Dec 29, 2008 at 9:55 AM, Andreas Goebel  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?

2008-11-20 Thread Csaba Halász
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?

2008-11-20 Thread Csaba Halász
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?

2008-11-20 Thread Csaba Halász
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?

2008-11-20 Thread Csaba Halász
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?

2008-11-19 Thread Csaba Halász
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] CompositeViewer addView threading issue on Windows?

2008-11-19 Thread Csaba Halász
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] Introducing osgmemorytest

2008-11-11 Thread Csaba Halász
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?

2008-11-07 Thread Csaba Halász
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

2008-11-06 Thread Csaba Halász
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] Freeze in ThreadPerCamera

2008-11-06 Thread Csaba Halász
On Thu, Nov 6, 2008 at 10:04 AM, Johannes Nilsson
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have had some problems with OSG freezing when running in
> ThreadPerCamera mode. My problems
> were resolved with two changes:
>
> The first one changes the order of the startRenderingBarrier and the
> reset of the endDynamicDrawBlock.
> This makes sure that the reset of the _endDynamicDrawBlock is done
> before the rendering begins.

I have run into this too, and submitted the same fix.

-- 
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?

2008-11-03 Thread Csaba Halász
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] deadlock loading io plugin?

2008-11-03 Thread Csaba Halász
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] mingw build problems

2008-10-30 Thread Csaba Halász
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


Re: [osg-users] mingw build problems

2008-10-29 Thread Csaba Halász
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] mingw build problems

2008-10-29 Thread Csaba Halász
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

2008-10-29 Thread Csaba Halász
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


[osg-users] mingw build problems

2008-10-29 Thread Csaba Halász
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] Call for feedback : AC3D loader behavior w.r.t texture repeat and clamping

2008-10-27 Thread Csaba Halász
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

2008-10-23 Thread Csaba Halász
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] [osg-submissions] AC3D Texture clamping

2008-10-20 Thread Csaba Halász
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] possible threading-related crash with on-screen stats

2008-10-20 Thread Csaba Halász
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


[osg-users] possible threading-related crash with on-screen stats

2008-10-19 Thread Csaba Halász
Hello,

In the osgcamera example I disable draw serialization like this:

Index: osgcamera.cpp
===
--- osgcamera.cpp   (revision 9034)
+++ osgcamera.cpp   (working copy)
@@ -204,6 +204,7 @@
 while (arguments.read("-g")) {
viewer.setThreadingModel(osgViewer::Viewer::CullDrawThreadPerContext);
}
 while (arguments.read("-d")) {
viewer.setThreadingModel(osgViewer::Viewer::DrawThreadPerContext); }
 while (arguments.read("-c")) {
viewer.setThreadingModel(osgViewer::Viewer::CullThreadPerCameraDrawThreadPerContext);
}
+osg::DisplaySettings::instance()->setSerializeDrawDispatch(false);

 bool limitNumberOfFrames = false;
 unsigned int maxFrames = 10;

I start it on a dual-core machine with the following command line:
./osgcamera -2 --CullDrawThreadPerContext cow.osg (side note: argument
parsing is wrong, -g or -c does not work)
It runs, as long as I don't bring up the stats graph, because that
causes a crash within a couple of seconds either with a segfault or
with memory corruption message, such as:
*** glibc detected *** ./osgcamera: malloc(): memory corruption
(fast): 0x2aaab81e6c2f ***
Sometimes, but not always, preceded by a number of "Warning: detected
OpenGL error 'invalid operation' after RenderBin::draw(,)" messages.

Anybody else see this?
Are there any known caveats with disabling draw serialization?

-- 
Thanks,
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

2008-10-17 Thread Csaba Halász
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


[osg-users] [osg-submissions] AC3D Texture clamping

2008-10-17 Thread Csaba Halász
Hi!

The texrep parsing change that went into the plugin about 2 weeks ago
is against the ac3d spec, that says:

*texrep %f %f

Optional - default 1.0,1.0 .  The texture repeat values for the tiling
of a texture
on an object's surfaces."

(http://www.inivis.com/ac3d/man/ac3dfileformat.html)

I believe this means the default behavior should be texture repeat
(assuming texrep 0 0 would disable repeat, which I am not sure of).
Can we please change it or at least have an option for it? In
flightgear a lot of models are suddenly broken because of this.

-- 
Thanks,
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

2008-10-16 Thread Csaba Halász
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] infinite block with CullThreadPerCameraDrawThreadPerContext

2008-10-16 Thread Csaba Halász
On Thu, Oct 16, 2008 at 10:43 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> Hi Csaba,
>
> Given the provided details I don't  have enough to provide an clues to
> what might be up.
>
> Try different threading models to see what results you get.
>
> Also try the standard OSG examples to see if any of them hang.

Hi Robert,

The other threading models seem to work, and the osg camera example
works with CullThreadPerCameraDrawThreadPerContext too.
I wonder if the problem reported by Paul in the mail thread "Please
test SVN of OpenSceneGraph in prep for 2.7.3 dev release" may be
related to this one. I have been able to reproduce that with an older
nvidia driver, but since I upgraded to 177.80 osgcamera works ok.

If I read the code right, during a frame all threads enter through the
_startRenderingBarrier, then the cull threads do the work while the
matching draw threads are blocked, then finally the draw is done. The
way I see it, one of the draw threads is still blocked waiting for the
cull to happen. I'll try to add some more debug printouts, but I am
still open to ideas :)

-- 
Greets,
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?

2008-10-16 Thread Csaba Halász
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] Reporting Builds

2008-10-15 Thread Csaba Halász
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] Reporting Builds

2008-10-15 Thread Csaba Halász
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

2008-10-15 Thread Csaba Halász
Hi,

I have set up a nightly 64 bit linux build (I guess you'll get more of
those) that seems to work fine.
Do we have fancy stuff like coverage, valgrind or tests? Also, I
wonder if you want a build from scratch? That took like 3 hrs :)

I also tried a mingw build, that seems to work too but the submission doesn't:

Testing completed

Submit Nightly

Beginning Submission

Built target Nightly


Any ideas?

-- 
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

2008-10-15 Thread Csaba Halász
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=, mutex=)
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=)
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] OpenThreads/pthreads & OpenMP on RHEL5.2

2008-10-15 Thread Csaba Halász
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


Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

2008-10-15 Thread Csaba Halász
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

2008-10-15 Thread Csaba Halász
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 :)

-- 
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

2008-10-15 Thread Csaba Halász
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

2008-10-15 Thread Csaba Halász
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

2008-10-15 Thread Csaba Halász
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

2008-10-15 Thread Csaba Halász
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] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release

2008-10-08 Thread Csaba Halász
On Tue, Oct 7, 2008 at 11:04 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
> 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 ;)

That was meant as a joke, but in fact that's just what happened.
Upgrading to 177.80 cured it.
Didn't get any more fps, though :'(

-- 
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

2008-10-07 Thread Csaba Halász
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] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release

2008-10-07 Thread Csaba Halász
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] Segfault in VTP, but looks like OSG

2008-06-03 Thread Csaba Halász
On Tue, Jun 3, 2008 at 10:20 PM,  <[EMAIL PROTECTED]> wrote:
>
> Especially since after osg::Transform (the direct ancestor of
> osg::MatrixTransform) is constructed the _prvData member is a valid
> pointer, and immediately after osg::MatrixTransform's constructor executes
> the _prvData member is zeroed.

You could try using a gdb watchpoint to identify exactly where the
member is zeroed.
Might be a memory corruption/buffer overflow issue.

-- 
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 :-)

2008-06-03 Thread Csaba Halász
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


Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)

2008-06-03 Thread Csaba Halász
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