Re: [osg-users] VBO fallback behavior and virtual machines
Hi Judson, On 21 March 2013 20:26, Judson Weissert jud...@mfrac.com wrote: There is an interesting distinction between needing to dirty a display list (e.g., Drawable::dirtyDisplayList()) versus having to dirty a primitive when using VBO (e.g., Array::dirty()). When a VBO request falls back to a display list implementation, it is possible that a call to dirtyDisplayList() in client code could be missing (because the primitive array was dirtied instead of the display list for instance). Not that this is a major issue, but it is something to think about when fallback is a possibility. There is only so much we can do as a fallback, both from a practicality and efficiency standpoint. As a general practice I'd recommend calling dirtyDisplayList() when you have modified the geometry, or disabling use of display lists. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO fallback behavior and virtual machines
Hi Judson, You're welcome. Happy to help. Cheers, Garth On 22/03/13 00:26, Judson Weissert wrote: Garth, Thank you for the information. Knowing that you got it to work in an embedded (non-fullscreen) window w/ 3D acceleration enabled is helpful. I should have posted my environment information in my previous posts: - VirtualBox 4.2.10 - OSG 3.1.2 (dev release) - ATI RadeonHD 5700 series with atiumdag 9.2.0.0 (Catalyst 12.10) driver - Host Windows 7 64-bit - Guest Windows 7 Ultimate N 64-bit Thanks, Judson On 3/20/2013 10:36 PM, Garth D wrote: Hi Judson, On 20/03/13 09:57, Judson Weissert wrote: Has anyone had success viewing their models using VirtualBox? I can confirm textured static and animated models work fine in my app under VirtualBox. I use it as a test environment in my development setup semi-regularly. - Host: Debian Linux 6.0.6 - Guest: Windows XP - OpenSceneGraph 3.0.1 (with some small custom patches) - VirtualBox 4.2.4 r81684 with 3D acceleration enabled - Host hardware is nVidia-based. If more detail on the above would help, just let me know. I run my app windowed, in a small window. Never tried it fullscreen. It's not fast. My demands on it aren't too high. Be careful of shadows though- I've had issues. Sorry that I can't be more specific, but consider disabling shadows as a test if you're having problems. Personally, I don't bother with the non-3D-accelerated setup with VirtualBox any more, because almost everything 3D-related breaks or is unusably slow. If you're developing, you control the hardware. For users, I'd imagine the cases where someone expects to run VirtualBox as a user *and* wants to disable 3D acceleration for a 3D app are very rare. For this reason, I just stick with the enabled setup. Since the 3D acceleration mode works as a pass-through to the host of sorts, having well-behaved 3D hardware on the host is essential. I've mostly stuck with nVidia cards for this purpose. I don't know about ATI, but they'd probably be fine. It's been a while since I've used VMware for this purpose, but I *think* OSG was one of the few engines that could cope with it. I haven't used VMware for a few years now though. I hope this helps. Cheers, Garth ___ 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
[osg-users] potential deadlock in viewer threading
Hi Robert
I discovered an issue with multithreading. Consider the following Code in
ViewerBase::startThreading:
Code:
void ViewerBase::startThreading()
{
if (_threadingModel==CullThreadPerCameraDrawThreadPerContext
numThreadsOnStartBarrier1)
{
Cameras::iterator camItr;
for(camItr = cameras.begin();
camItr != cameras.end();
++camItr)
{
osg::Camera* camera = *camItr;
if (camera-getCameraThread()
!camera-getCameraThread()-isRunning())
{
OSG_INFO camera-getCameraThread()-
camera-getCameraThread()std::endl;
[b] camera-getCameraThread()-startThread();[/b]
}
}
}
for(citr = contexts.begin();
citr != contexts.end();
++citr)
{
osg::GraphicsContext* gc = (*citr);
if (gc-getGraphicsThread() !gc-getGraphicsThread()-isRunning())
{
OSG_INFO gc-getGraphicsThread()-startThread()
gc-getGraphicsThread()std::endl;
[b]gc-getGraphicsThread()-startThread();[/b]
// OpenThreads::Thread::YieldCurrentThread();
}
}
_threadsRunning = true;
OSG_INFOSet up threadingstd::endl;
}
We suppose that each call to startThread actually starts the tread. When the
call returns the thread is actually running.
BUT: there are cases where for some reason the thread was not able to start. We
had such a issue where our 32-bit process was running on 3GB memory limit and
the thread was refused !! There might be other cases , errno is your friend in
telling you what was the reason (so was for me).
Actually Thread::startThread returns an int which is non-zero for such cases.
You should update the startThreading method to react accordingly when such an
error case occures. Otherwise OSG assumes that threads are running, but nothing
is happening and some thread sync wait calls end up dead-locked!
Regards
Daniel
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=53204#53204
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] potential deadlock in viewer threading
Hi Daniel,
Thanks for the bug report/characterization. I haven't looked at the
code yet, but your suggestion of checking return values sounds
reasonable, and would suggest falling back to single threaded when
this happens.
I suspect when hitting memory limits you'll start to see other
problems as well so the single threaded fallback is likely only a
solution for the deadlocks.
Could you have a bash at making modifications to
ViewBase::startThreading() to see if using a SingleThreaded fallback
works? If so then I can merge this change.
Robert.
On 22 March 2013 10:43, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote:
Hi Robert
I discovered an issue with multithreading. Consider the following Code in
ViewerBase::startThreading:
Code:
void ViewerBase::startThreading()
{
if (_threadingModel==CullThreadPerCameraDrawThreadPerContext
numThreadsOnStartBarrier1)
{
Cameras::iterator camItr;
for(camItr = cameras.begin();
camItr != cameras.end();
++camItr)
{
osg::Camera* camera = *camItr;
if (camera-getCameraThread()
!camera-getCameraThread()-isRunning())
{
OSG_INFO camera-getCameraThread()-
camera-getCameraThread()std::endl;
[b] camera-getCameraThread()-startThread();[/b]
}
}
}
for(citr = contexts.begin();
citr != contexts.end();
++citr)
{
osg::GraphicsContext* gc = (*citr);
if (gc-getGraphicsThread() !gc-getGraphicsThread()-isRunning())
{
OSG_INFO gc-getGraphicsThread()-startThread()
gc-getGraphicsThread()std::endl;
[b]gc-getGraphicsThread()-startThread();[/b]
// OpenThreads::Thread::YieldCurrentThread();
}
}
_threadsRunning = true;
OSG_INFOSet up threadingstd::endl;
}
We suppose that each call to startThread actually starts the tread. When the
call returns the thread is actually running.
BUT: there are cases where for some reason the thread was not able to start.
We had such a issue where our 32-bit process was running on 3GB memory limit
and the thread was refused !! There might be other cases , errno is your
friend in telling you what was the reason (so was for me).
Actually Thread::startThread returns an int which is non-zero for such cases.
You should update the startThreading method to react accordingly when such an
error case occures. Otherwise OSG assumes that threads are running, but
nothing is happening and some thread sync wait calls end up dead-locked!
Regards
Daniel
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=53204#53204
___
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] VBO fallback behavior and virtual machines
On 3/22/2013 4:56 AM, Robert Osfield wrote: Hi Judson, On 21 March 2013 20:26, Judson Weissert jud...@mfrac.com wrote: There is an interesting distinction between needing to dirty a display list (e.g., Drawable::dirtyDisplayList()) versus having to dirty a primitive when using VBO (e.g., Array::dirty()). When a VBO request falls back to a display list implementation, it is possible that a call to dirtyDisplayList() in client code could be missing (because the primitive array was dirtied instead of the display list for instance). Not that this is a major issue, but it is something to think about when fallback is a possibility. There is only so much we can do as a fallback, both from a practicality and efficiency standpoint. As a general practice I'd recommend calling dirtyDisplayList() when you have modified the geometry, or disabling use of display lists. Robert. I concur. Also, I learned why the viewer was opening in full screen when running in VirtualBox with 3D Acceleration enabled. I foolishly did not check the return value of osg::GraphicsContext::createGraphicsContext() to ensure it was valid before assigning it to my camera. Therefore, when osg::Viewer::realize() was called later, it detected it was not fully initialized, so it went on to create its own fullscreen window. Apparently, a pixel format could not be created that matched my traits. Specifically, when I specified 4 samples (associated with WGL_SAMPLES_ARB), choosing a pixel format failed, but it succeeds with a value of zero (which also explains how the fullscreen window was able to function). Thanks again, Judson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPPU] osgPPU and wireframe
Hi all Maybe you noticed that when using osgPPU and pressing 'w' to change the polygon mode to wireframe, the screen goes black, because only the screenquad is rendered in wireframe, but the actual scene is not rendered anymore. Does anybody know how to change this? Thank you! Cheers, Daniel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=53207#53207 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] osgPPU and wireframe
Hi Daniel, You will need to apply an osg::PolygonMode attribute to the screenquad stateset with the mode set to osg::PolygonMode::FILL. I haven't used osgPPU, but I've used this when displaying fullscreen quads with rendered textures and it worked fine. Cheers, Farshid On Fri, Mar 22, 2013 at 7:51 AM, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote: Hi all Maybe you noticed that when using osgPPU and pressing 'w' to change the polygon mode to wireframe, the screen goes black, because only the screenquad is rendered in wireframe, but the actual scene is not rendered anymore. Does anybody know how to change this? Thank you! Cheers, Daniel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=53207#53207 ___ 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
