Re: [osg-users] NVIDIA Driver Problem?
Hi J.P. On 29 November 2011 09:52, J.P. Delport jpdelp...@csir.co.za wrote: can it have something to do with: static RegisterWindowingSystemInterfaceProxy createWindowingSystemInterfaceProxy; in GraphicsWindowX11? The proxy registers a X11WindowingSystemInterface object that is used to create the contexts on demand, but it this doesn't cache any contexts. There is code in the constructor of X11WindowingSystemInterface for registering a custom error handler but I wouldn't have thought this would cause problems. One could comment out the error handling setup to see if this makes a difference. All the other functionality of X11WindowSystemInterface is provided on demand, there isn't any caching of handles to X11 so won't cause problems. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
Hi Paul, On 15 November 2011 13:04, Paul Palumbo paul1...@yahoo.com wrote: The probably is evident when the X server is restarted between these calls to create the osgViewer::Viewer. I don't think it matters any if the restart is inside the program or not as long as it happens when no osgViewer::Viewer is active. The only GLX code in osgViewer is in GraphicsWindowX11.cpp and PixelBufferX11.cpp. Each of GraphicsWindowX11 and PixelBufferX11 keep their own local handles to X11 objects and should be cleaning these up when they are closed/destructed, I don't recall any global handles that will need cleaning up. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
Hi, On 29/11/2011 11:34, Robert Osfield wrote: Hi Paul, On 15 November 2011 13:04, Paul Palumbopaul1...@yahoo.com wrote: The probably is evident when the X server is restarted between these calls to create the osgViewer::Viewer. I don't think it matters any if the restart is inside the program or not as long as it happens when no osgViewer::Viewer is active. The only GLX code in osgViewer is in GraphicsWindowX11.cpp and PixelBufferX11.cpp. Each of GraphicsWindowX11 and PixelBufferX11 keep their own local handles to X11 objects and should be cleaning these up when they are closed/destructed, I don't recall any global handles that will need cleaning up. can it have something to do with: static RegisterWindowingSystemInterfaceProxy createWindowingSystemInterfaceProxy; in GraphicsWindowX11? rgds jp Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
Repeatedly calling osgviewer cow.osg is not the problem. This works just fine. If there is a problem in OSG, it is probably in that a resource associated with osgViewer::Viewer isn't being freed unless the application exits. I've had this same problem before and Robert fixed a GL resource cleanup problem. The probably is evident when the X server is restarted between these calls to create the osgViewer::Viewer. I don't think it matters any if the restart is inside the program or not as long as it happens when no osgViewer::Viewer is active. No fear in restarting the X server. I do it about 20-30 times a day :-). Paul P. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43893#43893 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] NVIDIA Driver Problem?
Can somebody do a test for me? I'm using OSG 3.0.0 and this works with NVIDIA
Driver (Linux) 260.19.21 but doesn't seem to work with newer versions of the
driver (e.g. 275.31 beta) with no other changes being made. I've been in
contact with NVIDIA with this problem and they seem to think that it is an OSG
problem.
I'm having trouble when I create an osgViewer, destroy it, restart the X server
and then create the osgViewer. I've boiled my problem down to a small test
case in the attached file which is a slightly modified version of osgviewer.
I know this test case is somewhat convoluted but bare with me. Our application
is required to restart the X server before starting to display an image.
Normally, osgviewer would do the following:
1) osgViewer::Viewer viewer(arguments);
2) viewer.setSceneData( loadedModel.get() );
3) viewer.realize();
4) viewer.run();
5) exit(0);
I have modified it to do the following:
Code:
while (forever)
{
{ // Define a scope of the osgViewer::Viewer
osgViewer::Viewer viewer(arguments);
viewer.setSceneData( loadedModel.get() );
viewer.realize();
viewer.run();
} // osgViewer::Viewer scope has ended and its destructor called.
sleep(2);
system(“/usr/sbin/gdm-restart”);
sleep(20);
}
Compile and run this program. Since this program restarts the X server (with
the gdm-restart command) and attempts to display an image, you will need use
two machines (a remote machine and a target machine). Running this using one
machine will cause the program to be killed when the X server is restarted. To
run this program, do the following:
a. On the console of the target machine, login normally. Open a terminal
window and type “xhost +”
b. From a remote computer login to your target machine and “setenv DISPLAY
:0.0” to keep the display on the remote machine.
c. From this remote computer window, run the attached version of osgviewer as
“osgviewer cow.osg”.
d. Hit the escape key on the target machine to dismiss the cow being
displayed.
e. At this point, the target machine X server will restart. IMMEDIATELY after
the X server has restarted, login to the target machine again from its
console. Open a terminal window and select “xhost +” again. It you don't do
this last part, you will not have permissions to display an image on the
target machine from the remote machine. The program will give you 20 second
before it attempts to display an image on on the target machine.
f. At this point, you should see a cow image on the display but with this new
driver, we’ve been seeing a totally black image.
When I run this program, instead of seeing the cow image the second time, I'm
seeing a black screen. I didn't see this problem with earlier version of the
NVIDIA driver (also using OSG 3.0.0).
Is anybody else having this problem?
Paul P.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43865#43865
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restriction, both in commercial and non commercial
applications,
* as long as this copyright notice is maintained.
*
* This application is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
#include osgDB/ReadFile
#include osgUtil/Optimizer
#include osg/CoordinateSystemNode
#include osg/Switch
#include osgText/Text
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/StateSetManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator
#include osgGA/SphericalManipulator
#include iostream
int main(int argc, char** argv)
{
// use an ArgumentParser object to manage the program arguments.
osg::ArgumentParser arguments(argc,argv);
arguments.getApplicationUsage()-setApplicationName(arguments.getApplicationName());
arguments.getApplicationUsage()-setDescription(arguments.getApplicationName()+
is the standard OpenSceneGraph example which loads and visualises 3d models.);
arguments.getApplicationUsage()-setCommandLineUsage(arguments.getApplicationName()+
[options] filename ...);
arguments.getApplicationUsage()-addCommandLineOption(--image
filename,Load an image and render it on a quad);
arguments.getApplicationUsage()-addCommandLineOption(--dem
filename,Load an image/DEM and render it on a HeightField);
arguments.getApplicationUsage()-addCommandLineOption(--login url
username password,Provide authentication information for http file
access.);
unsigned int helpType = 0;
if ((helpType = arguments.readHelpType()))
{
Re: [osg-users] NVIDIA Driver Problem?
paul1492 wrote:
Can somebody do a test for me? I'm using OSG 3.0.0 and this works with NVIDIA
Driver (Linux) 260.19.21 but doesn't seem to work with newer versions of the
driver (e.g. 275.31 beta) with no other changes being made. I've been in
contact with NVIDIA with this problem and they seem to think that it is an
OSG problem.
I'm having trouble when I create an osgViewer, destroy it, restart the X
server and then create the osgViewer. I've boiled my problem down to a small
test case in the attached file which is a slightly modified version of
osgviewer.
I know this test case is somewhat convoluted but bare with me. Our
application is required to restart the X server before starting to display an
image.
Normally, osgviewer would do the following:
1) osgViewer::Viewer viewer(arguments);
2) viewer.setSceneData( loadedModel.get() );
3) viewer.realize();
4) viewer.run();
5) exit(0);
I have modified it to do the following:
Code:
while (forever)
{
{ // Define a scope of the osgViewer::Viewer
osgViewer::Viewer viewer(arguments);
viewer.setSceneData( loadedModel.get() );
viewer.realize();
viewer.run();
} // osgViewer::Viewer scope has ended and its destructor called.
sleep(2);
system(“/usr/sbin/gdm-restart”);
sleep(20);
}
Compile and run this program. Since this program restarts the X server (with
the gdm-restart command) and attempts to display an image, you will need use
two machines (a remote machine and a target machine). Running this using one
machine will cause the program to be killed when the X server is restarted.
To run this program, do the following:
a. On the console of the target machine, login normally. Open a terminal
window and type “xhost +”
b. From a remote computer login to your target machine and “setenv DISPLAY
:0.0” to keep the display on the remote machine.
c. From this remote computer window, run the attached version of osgviewer
as “osgviewer cow.osg”.
d. Hit the escape key on the target machine to dismiss the cow being
displayed.
e. At this point, the target machine X server will restart. IMMEDIATELY
after the X server has restarted, login to the target machine again from
its console. Open a terminal window and select “xhost +” again. It you
don't do this last part, you will not have permissions to display an image
on the target machine from the remote machine. The program will give you 20
second before it attempts to display an image on on the target machine.
f. At this point, you should see a cow image on the display but with this
new driver, we’ve been seeing a totally black image.
When I run this program, instead of seeing the cow image the second time, I'm
seeing a black screen. I didn't see this problem with earlier version of the
NVIDIA driver (also using OSG 3.0.0).
Is anybody else having this problem?
Paul P.
Greetings!
Since your so lucky to try out one of NVidea Beta Drivers, have you ran this
across the NVidia test team first? Also, I didn't get what Graphics Card you
are using!
That is where I would go with this! OSG works on top of OpenGL other than that
it is doing nothing directly with the card.
If your using beta, I would look towards the fact that it may be still buggy!
Also, it has been my experience with NVidia that newer drivers in Linux, don't
necessary mean that it's an improvement. I have had to backtrack on drivers
even on my OpenGL code stuff because Nividia broke something in the process.
They are more concerned over a Windows driver than Linux I think!
David Glenn
---
D Glenn 3D Computer Graphics amp; Media Systems.
www.dglenn.com
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43874#43874
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
dglenn wrote: Greetings! Since your so lucky to try out one of NVidea Beta Drivers, have you ran this across the NVidia test team first? Also, I didn't get what Graphics Card you are using! That is where I would go with this! OSG works on top of OpenGL other than that it is doing nothing directly with the card. If your using beta, I would look towards the fact that it may be still buggy! Also, it has been my experience with NVidia that newer drivers in Linux, don't necessary mean that it's an improvement. I have had to backtrack on drivers even on my OpenGL code stuff because Nividia broke something in the process. They are more concerned over a Windows driver than Linux I think! Sorry that's about all I can help you at this point! I was given this Beta driver by NVIDIA to fix another problem. That other problem seems to have been fixed but then two other problems showed up. One I found a work around for and this is the other. As I said in my earlier post, my Point-Of-Contact at NVIDIA seems to dismiss the new problem as an OSG problem even though the problem showup with only a drive change. I've tried new non-beta drivers and I believe I have the same problem. FYI: I'm using a Quadro 5000. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43876#43876 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
Paul, Have you done a search in this mailing list/forum for nvidia 275? Follow some of the threads you find, and see if any help you track down or fix your problem. Due to previous discussions on the topic, I have been careful to generally avoid this specific driver. I hope this helps... D.J. On Mon, Nov 14, 2011 at 5:08 PM, Paul Palumbo paul1...@yahoo.com wrote: dglenn wrote: Greetings! Since your so lucky to try out one of NVidea Beta Drivers, have you ran this across the NVidia test team first? Also, I didn't get what Graphics Card you are using! That is where I would go with this! OSG works on top of OpenGL other than that it is doing nothing directly with the card. If your using beta, I would look towards the fact that it may be still buggy! Also, it has been my experience with NVidia that newer drivers in Linux, don't necessary mean that it's an improvement. I have had to backtrack on drivers even on my OpenGL code stuff because Nividia broke something in the process. They are more concerned over a Windows driver than Linux I think! Sorry that's about all I can help you at this point! I was given this Beta driver by NVIDIA to fix another problem. That other problem seems to have been fixed but then two other problems showed up. One I found a work around for and this is the other. As I said in my earlier post, my Point-Of-Contact at NVIDIA seems to dismiss the new problem as an OSG problem even though the problem showup with only a drive change. I've tried new non-beta drivers and I believe I have the same problem. FYI: I'm using a Quadro 5000. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43876#43876 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
D.J. Caldwell wrote: Paul, Have you done a search in this mailing list/forum for nvidia 275? Follow some of the threads you find, and see if any help you track down or fix your problem. Due to previous discussions on the topic, I have been careful to generally avoid this specific driver. I hope this helps... D.J. On Mon, Nov 14, 2011 at 5:08 PM, Paul Palumbo () wrote: dglenn wrote: Greetings! Since your so lucky to try out one of NVidea Beta Drivers, have you ran this across the NVidia test team first? Also, I didn't get what Graphics Card you are using! That is where I would go with this! OSG works on top of OpenGL other than that it is doing nothing directly with the card. If your using beta, I would look towards the fact that it may be still buggy! Also, it has been my experience with NVidia that newer drivers in Linux, don't necessary mean that it's an improvement. I have had to backtrack on drivers even on my OpenGL code stuff because Nividia broke something in the process. They are more concerned over a Windows driver than Linux I think! Sorry that's about all I can help you at this point! I was given this Beta driver by NVIDIA to fix another problem. That other problem seems to have been fixed but then two other problems showed up. One I found a work around for and this is the other. As I said in my earlier post, my Point-Of-Contact at NVIDIA seems to dismiss the new problem as an OSG problem even though the problem showup with only a drive change. I've tried new non-beta drivers and I believe I have the same problem. FYI: I'm using a Quadro 5000. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43876#43876 (http://forum.openscenegraph.org/viewtopic.php?p=43876#43876) ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) -- Post generated by Mail2Forum Wow I knew that NVidia has been known to make a dud or two, but 275.33.x was a turkey! What can I say about it but I rest my case! I would try to use, maybe a 260.19.44 driver. I using that on a Quatro 4000 in my lab right now and it works very well! I do get rather irritated when a company can't fess-up to their mistakes and use the Not My Problem excuse! David Glenn --- D Glenn 3D Computer Graphics amp; Media Systems. www.dglenn.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43880#43880 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
Hi,
before I go restart X-servers all over the lab, can you give a bit more
info... :)
On 14/11/2011 20:13, Paul Palumbo wrote:
Can somebody do a test for me? I'm using OSG 3.0.0 and this works
with NVIDIA Driver (Linux) 260.19.21 but doesn't seem to work with
newer versions of the driver (e.g. 275.31 beta) with no other changes
being made. I've been in contact with NVIDIA with this problem and
they seem to think that it is an OSG problem.
I'm having trouble when I create an osgViewer, destroy it, restart
the X server and then create the osgViewer. I've boiled my problem
down to a small test case in the attached file which is a slightly
modified version of osgviewer.
I know this test case is somewhat convoluted but bare with me. Our
application is required to restart the X server before starting to
display an image.
Normally, osgviewer would do the following: 1) osgViewer::Viewer
viewer(arguments); 2) viewer.setSceneData( loadedModel.get() ); 3)
viewer.realize(); 4) viewer.run(); 5) exit(0);
I have modified it to do the following:
Code:
while (forever) { { // Define a scope of the osgViewer::Viewer
osgViewer::Viewer viewer(arguments); viewer.setSceneData(
loadedModel.get() ); viewer.realize(); viewer.run(); } //
osgViewer::Viewer scope has ended and its destructor called.
sleep(2); system(“/usr/sbin/gdm-restart”); sleep(20); }
Do you have to do the restart from a C++ app? What happens if you
manually restart gdm and then start another osg process? It might be
some GL resource that is only released when the process exits. Or a
windowing system static that OSG assumes is still valid, but is
obviously not since the gl driver restarted.
I know there was a discussion about static resources when e.g. using OSG
as part of a larger library or as a plugin. How does one get OSG into
its original state without restarting the process... I can go dig it up
if you want.
jp
Compile and run this program. Since this program restarts the X
server (with the gdm-restart command) and attempts to display an
image, you will need use two machines (a remote machine and a target
machine). Running this using one machine will cause the program to be
killed when the X server is restarted. To run this program, do the
following:
a. On the console of the target machine, login normally. Open a
terminal window and type “xhost +” b. From a remote computer login
to your target machine and “setenv DISPLAY :0.0” to keep the
display on the remote machine. c. From this remote computer window,
run the attached version of osgviewer as “osgviewer cow.osg”. d.
Hit the escape key on the target machine to dismiss the cow being
displayed. e. At this point, the target machine X server will
restart. IMMEDIATELY after the X server has restarted, login to the
target machine again from its console. Open a terminal window and
select “xhost +” again. It you don't do this last part, you will
not have permissions to display an image on the target machine from
the remote machine. The program will give you 20 second before it
attempts to display an image on on the target machine. f. At this
point, you should see a cow image on the display but with this new
driver, we’ve been seeing a totally black image.
When I run this program, instead of seeing the cow image the second
time, I'm seeing a black screen. I didn't see this problem with
earlier version of the NVIDIA driver (also using OSG 3.0.0).
Is anybody else having this problem?
Paul P.
-- Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43865#43865
___ osg-users mailing
list osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
