Hi all,
I don't know if anyone was interested in this issue, but after a few
more back-and-forths with the NVidia developers, we were able to
determine that the bug is completely fixed. I asked what the cause was,
and here was their answer:
There was a bug in our driver that had a race
Hi JS,
Thanks for the update, and info about the bug fix from NVidia. Kudos to
yourself and NVidia for getting this one put to bed.
On Tue, Apr 7, 2009 at 5:41 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Robert, I don't know how often you can update your graphics drivers,
Hi Robert,
We'll right now I'm working on ATI graphics card ;-)
Booo :-)
I'm sure this is very low on your priority list, but any chance you'll
get the stats handler's GPU time to show up on ATI cards? :-)
A quick check of the Ubunutu repositories suggest that leatest NVidia
drive
On Tue, Apr 7, 2009 at 6:30 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
We'll right now I'm working on ATI graphics card ;-)
Booo :-)
I'm sure this is very low on your priority list, but any chance you'll get
the stats handler's GPU time to show up on ATI cards? :-)
Hi Robert,
Does ATI support any GPU query extensions? The OSG code is not specific
to NVidia.
It seems that it doesn't support those extensions, no (note that I
haven't looked at it specifically, just relying on the effect which is
that the GPU time line is missing in the stats handler).
Robert Osfield wrote:
On Tue, Apr 7, 2009 at 6:30 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com
mailto:jean-sebastien.g...@cm-labs.com wrote:
We'll right now I'm working on ATI graphics card ;-)
Booo :-)
I'm sure this is very low on your priority list, but any
On Tue, Apr 7, 2009 at 7:16 PM, Jason Daly jd...@ist.ucf.edu wrote:
This one looks promising:
AMD_performance_monitor
http://www.opengl.org/registry/specs/AMD/performance_monitor.txt
Thanks for link. Does look like it may well do the trick. I'll have to
dive in fully really know how
Hi Robert,
GL_EXT_timer_query extension is the vendor independent extension, it
just that AMD has clearly gone a different route.
Well, it's vendor independent but only NVidia implements it. ;-) It
could as well be an NV extension, no one else supports it (not just
ATI/AMD, but no one
Hi Robert,
It seems that it doesn't support those extensions, no (note that I
haven't looked at it specifically, just relying on the effect which is
that the GPU time line is missing in the stats handler).
GLView tells me that according to its database, only NVidia cards
(GeForce and Quadro
Hi all,
Some progess on this issue, at last!
Quoting myself:
I might try submitting the modified example to nvidia to see if they can
confirm a bug.
I sent a bug report to nvidia a little while back, and got an answer
last Friday saying that with the newest drivers, they could only
Hi JS,
On Tue, Jan 13, 2009 at 7:01 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Have you had any time to look into this? (I'm doing some gentle poking from
time to time, but my goal is just to follow up, not to try and affect your
priorities in any way...)
I couldn't find
Hi Robert,
I couldn't find the cause or any workaround. I tried a range of
things to try and characterise and track down the cause of bug but
came away without any better idea then when I started. In
osgViewer/View.cpp I implemented proper setup of the number of context
supported by the scene
Hi JS,
On Wed, Jan 14, 2009 at 2:19 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
I might try submitting the modified example to nvidia to see if they can
confirm a bug. By coincidence, I just recently read their developer FAQ, and
they say they generally don't need the
Hi Robert,
The other way to do tackle this type of usage model would be to have
all the cameras share a single GraphicsWindow and have the OSG manage
the various views. This is likely to produce the best performance and
scalability, having all these separate graphics contexts really isn't
good
Hi Robert,
I might try submitting the modified example to nvidia to see if they can
confirm a bug.
Can I get your system stats (CPU, GPU, driver version, kernel perhaps,
anything else you think is relevant) please? Just so I can quote the
exact Linux system on which this was reproduced.
On Wed, Jan 14, 2009 at 5:20 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Can I get your system stats (CPU, GPU, driver version, kernel perhaps,
anything else you think is relevant) please? Just so I can quote the exact
Linux system on which this was reproduced.
Distro:
Hi Robert,
I've just run it on my new machine and after a the fourth 'a' the
application hangs. So I'm finally able to reproduce the bug. I've
spent a bit of time in gdb but haven't got any clues yet as to the
cause.
Have you had any time to look into this? (I'm doing some gentle poking
Hi Robert,
(if it didn't break threading I'd really change that subject line,
others have tested and have reproduced the issue on Linux so it's not
Windows-specific...)
Whether the new system will work properly right away and if to does
will it reproduce the hang I don't know untill I get
Hi J-S,
On Thu, Dec 18, 2008 at 2:41 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Sorry to bother you, but have you had a chance to test my modified
osgcompositeviewer example on your new machine?
No, not up to you bothered me again :-)
I've just run it on my new machine and
Hi Robert,
I've just run it on my new machine and after a the fourth 'a' the
application hangs. So I'm finally able to reproduce the bug. I've
spent a bit of time in gdb but haven't got any clues yet as to the
cause.
I don't think I've ever been happier to have someone tell me that a
Hi J-S,
It's interesting that opening up the windows at the start allows
things to run, this suggest that it's allocation of new OpenGL that is
problem - which is something that the resize of the GL buffers would
have done the trick.
W.r.t opening 40 windows and the app crashing - this is almost
Hi Robert,
I forgot to mention that this is running with OSG as compiled yesterday
afternoon after an svn update.
It's interesting that opening up the windows at the start allows
things to run, this suggest that it's allocation of new OpenGL that is
problem - which is something that the
Hi JS,
On Thu, Nov 20, 2008 at 7:12 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
As we don't know whether this is the cause of the problem yet, I've
modified J-S's osgviewer.cpp to do the resize. Could users who've
seen problems try this version out, if this works then we have
workaround
Hi JS,
Robert, what driver version are you using? Any chance
OpenGL version string: 2.1.1 NVIDIA 100.14.19
Intel Quad core, Kubuntu 7.10.
On Thu, Nov 20, 2008 at 2:40 AM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
Also, any chance this has a connection with the buffered_value thread? Seems
Hi all,
Thanks for testing again. I've had a few other reports for Linux and
Windows, some can repro others can't, so I'm trying to get hardware
details and driver versions to see if it could be dependent of these
factors. Thanks for providing them.
Robert suggested off-list that I post
Hi Robert,
OpenGL version string: 2.1.1 NVIDIA 100.14.19
Intel Quad core, Kubuntu 7.10.
Hmmm, seems older than what JP and Csaba reported? Or am I reading the
numbers wrong?
The OSG's buffer_arrays that manage the OpenGL contexts might not be
being resized correctly, and this is something
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.
Hi,
Jean-Sébastien Guay wrote:
Hi Robert,
OpenGL version string: 2.1.1 NVIDIA 100.14.19
Intel Quad core, Kubuntu 7.10.
Hmmm, seems older than what JP and Csaba reported? Or am I reading the
numbers wrong?
Yes, it's older. Website says 100.14.19 = Sept 2007. Think I'll have to
downgrade
Hi J.P. et al.,
On Thu, Nov 20, 2008 at 3:01 PM, J.P. Delport [EMAIL PROTECTED] wrote:
Yes, it's older. Website says 100.14.19 = Sept 2007. Think I'll have to
downgrade kernel to a version that would be happy with older NVidia driver.
Robert what kernel version are you using?
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
Hi Csaba et. al,
On Thu, Nov 20, 2008 at 3:50 PM, Csaba Halász [EMAIL PROTECTED] wrote:
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
Hi All,
On Thu, Nov 20, 2008 at 4:01 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
I think the best lead would be that perhaps the texture object/display
lists buffer_value containers aren't being resized to fit the new
number of contexts which the app is running single threaded. In
theory
Hi J-S, J.P., and non-initialed persons of interest (or P.O.I.s),
J-S beat me and posted the traces I mailed to him off-line yesterday. I was
doing another round of tests to see if I could really duplicate his exact
problem. I can't. I don't get the hang unless I change the threading model.
Interesting. My system sparky has
OpenGL version string: 2.1.1 NVIDIA 100.14.19
AMD-64, SuSe 9.2 (I think) rather old kernel 2.4.21-102-smp
-Don
Robert, what driver version are you using? Any chance
OpenGL version string: 2.1.1 NVIDIA 100.14.19
Intel Quad core, Kubuntu 7.10.
Hi Robert,
As we don't know whether this is the cause of the problem yet, I've
modified J-S's osgviewer.cpp to do the resize. Could users who've
seen problems try this version out, if this works then we have
workaround that end users can apply to existing apps, and we can
figure out a solution
Hi Robert,
As we don't know whether this is the cause of the problem yet, I've
modified J-S's osgviewer.cpp to do the resize. Could users who've
seen problems try this version out, if this works then we have
workaround that end users can apply to existing apps, and we can
figure out a solution
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
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
Hi J-S,
I've just upgraded OSG on two Linux machines to latest svn and I can
still reproduce the hang with your example. I need to add around 8-12
new windows.
The one machine is a dual-core laptop with GeForce Go 7400. The other is
a quad-core desktop with a GTX280. Both are running Debian
Hi JP,
Thanks for testing again. I've had a few other reports for Linux and
Windows, some can repro others can't, so I'm trying to get hardware
details and driver versions to see if it could be dependent of these
factors. Thanks for providing them.
Not sure why Robert can't reproduce the
I tried J-S's test on a couple of systems in my office and got it to hang on
several. I'm using OSG 2.6.0 and our drivers are far from bleeding edge (some
are several years old). I think I have coaxed additional nastyness from the
test by typing an 'm' to change the threading model after each
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
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
Hi Csaba,
my call stacks show that all the waiting is going on because one of
the threads is stuck in makeCurrent:
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.
Yep, seems like that's the same
Hi all,
No answers yet, so either I was too verbose and scared off people or no
one has anything to say...
I should mention, I would be interested if someone would try the example
I attached to the last mail even on other platforms than Windows (Linux
mostly) to see if I'm doing anything
Hi,
ran it under Linux Nvidia 177.82.
First time freeze on adding 3rd extra view
2nd time freeze on adding 5th
3rd time freeze on adding 7th
4th time freeze on adding 4th
backtrace on last:
thread 0:
#0 0xb8022424 in __kernel_vsyscall ()
#1 0xb7732025 in pthread_cond_wait@@GLIBC_2.3.2 ()
] CompositeViewer addView threading issue on Windows?
Hi all,
No answers yet, so either I was too verbose and scared off people or no
one has anything to say...
I should mention, I would be interested if someone would try the example
I attached to the last mail even on other platforms than
Hello John,
No answers, but I have seen in my own work that adding a new view to an existing (and running) CompositeViewer causes a crash when the CompositeViewer was running in anything other than single-threaded mode when it tries to stop the thread to add the new view (inside
Hi JS,
I could reproduce any crashes on press 'a' but on pressing escape the
code crashed due to a circular reference that your AddViewHandler
introduces with its local ref_ptrCompositeViewer. Changing this to
observer_ptr fixes the crash on exit.
W.r.t crash on add, I've pressed 'a' 20 times
Hi Robert,
Thanks a lot for testing.
I could reproduce any crashes on press 'a' but on pressing escape the
code crashed due to a circular reference that your AddViewHandler
introduces with its local ref_ptrCompositeViewer. Changing this to
observer_ptr fixes the crash on exit.
Yes of
On Tue, Nov 18, 2008 at 3:56 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
Any other ideas as to what I could be doing wrong?
No ideas sorry. Until I can reproduce the problem I'm not really in
position to contribute too much.
Robert.
___
51 matches
Mail list logo
