[osg-users] VBO fallback behavior and virtual machines

[Judson Weissert]

Hello,

I have been testing in VirtualBox recently, and encountered two problems
that I was hoping someone might recognize. Note: The problems do not
occur outside of a virtual environment.

1. I have geometry in my model where I call
osg::Geometry::setUseVertexBufferObjects(true), but the virtual
environment only supports OpenGL 1.1. An access violation occurs shortly
after calling glDrawElements() from DrawElementsUInt::draw().

The last portion of the call stack is as follows (access violation in
memcpy() trying to access 0x4fbc):

msvcrt.dll!memcpy() + 0x31 bytes

opengl32.dll!__gllc_ReducedElementsHandler() + 0x285 bytes

opengl32.dll!ReduceDrawElements() + 0x1cb bytes

opengl32.dll!__gllc_DrawElements() + 0x121 bytes

osg92-osg.dll!osg::DrawElementsUInt::draw(osg::State & state={...}, bool useVertexBufferObjects=false)

osg92-osg.dll!osg::Geometry::drawImplementation(osg::RenderInfo & renderInfo={...})


Taking out the call to setUseVertexBufferObjects() seems to fix the
problem. Do I have to detect the OpenGL version explicitly, or is the
OSG library supposed to fallback to a non-VBO mode of operation
automatically?

Also, prior to the crash, I get various "Error: glBufferData not
supported by OpenGL driver" notifications. Also a glGenBuffers() and
glBindBuffer() error notification, and a Windows error #127 that
mentions wglChoosePixelFormatARB ext not found.

2. If I enable 3D acceleration in VirtualBox, there is no crash, but the
scene ends up opening as a separate window and takes up the entire
screen. I am not sure how much this issue relates to OSG though.
Spy++ shows a window class of "OSG Graphics Window for Win32 [{with
cursor}]", that is not visible in Spy if the window opens as a child
window with a non-null parent as expected.

Has anyone had success viewing their models using VirtualBox? or VMWare?

Thanks,

Judson
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Robert Osfield]

Hi Judson,

I haven't played with using virtual machines for rendering so don't
have first hand experience. For item 1 - version detection and
extension usage, this should in theory work, with the OSG
automatically detecting OpenGL 1.1 and lack of VBO support and not
using it. The error you are seeing is either the driver claiming to
support VBO's or the OSG missing this check. Check what OpenGL
version is passed back.

Running the OSG with OSG_NOTIFY_LEVEL set to DEBUG or programatically
with osg::setNotifyLevel(osg::DEBUG_INFO); will report what version
and extensions are supported to the console, along with lots of other
stuff too, but redirect the output to a file and then browse through.
This should tell you what the OSG has got back from the driver.

Robert.

[Judson Weissert]

Hi Robert,

Thank you for the suggestion. I have attached the notify log. In summary, the log includes a number of entries for features not supported by the OpenGL driver, including GL_ARB_vertex_buffer_object. There are a number of glBufferData errors in the log, but I am not sure of their severity.

I did not see the OpenGL version reported in the log, but OpenGL Extension viewer reports 1.1 and also agrees with the extension support reported in the log.

I will continue to experiment.

Thanks,

Judson

--

Judson Weissert | Software Engineer
Baker Hughes | Pressure Pumping
Office: +1 724 224 1440 | Fax: +1 724 224 1442
jud...@mfrac.com | judson....@bakerhughes.com
http://www.mfrac.com | A Global Leader in Hydraulic Fracturing Software
http://www.bakerhughes.com | Advancing Reservoir Performance

[Judson Weissert]

Update:

In an effort to eliminate variables, I compiled the osggeometry example file and ran it in both inside and outside of VirtualBox. It ran fine for both cases. Then, I applied the attached patch and ran it again. The result was no crash outside of the virtual environment, and a crash inside the Virtual Environment. I am assuming the crash is the same, I need to do some additional debugging.

Regards,

Judson

On 3/20/2013 9:57 AM, Judson Weissert wrote:

[Garth D]

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

[Judson Weissert]

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

[Robert Osfield]

Hi Judson,

On 21 March 2013 13:56, Judson Weissert <jud...@mfrac.com> wrote:
> 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 for the details, this give us and others that follow along
after a bit more information of where problems might exist.

I've looked into the code that sets up the OpenGL side to the VBO's
from osg::Geometry and the key part is in include/osg/State's
setVertexPoint(..) etc. methods. In these I don't see any check for
VBO's being supported and no checks with the BufferData method that
gets the GLBufferObject structures so the code in include/osg/State
just merries goes along assuming everything is fine and tries to use
the VBO's. When binding the VBO's the code in
src/osg/BufferObject.cpp will be check for the extension support which
will avoid a crash in this code but later on when applying the array
data via glVertexPointer etc. calls it'll assume success and pass a
relative pointer rather than an absolute pointer which will result in
the crash you are seeing.

I haven't yet decided where abouts the best fix would be. Either a
variable in osg::State for whether VBO's are supported or a check in
BufferData::getOrCreateGLBufferObject. Currently my preference is to
put a variable in osg::State. There are other variables in osg::State
that are used for enabling/disabling OpenGL features so there is prior
art that could be used as template for this.

Robert.

[Judson Weissert]

Hi Robert,

Ah, in hind sight (after staring at the code for hours) this makes a lot
of sense.

> I haven't yet decided where abouts the best fix would be. Either a
> variable in osg::State for whether VBO's are supported or a check in
> BufferData::getOrCreateGLBufferObject. Currently my preference is to
> put a variable in osg::State. There are other variables in osg::State
> that are used for enabling/disabling OpenGL features so there is prior
> art that could be used as template for this.

It looks like osg::State already has that flag. See
osg::State::_isVertexBufferObjectSupportResolved, and
osg::State::isVertexBufferObjectSupported. Perhaps just the guard is
missing?

Thank you for looking into this. My OpenGL/OSG debugging skills are not
quite where they need to be yet.

Regards,

Judson

[Robert Osfield]

HI Judson,

On 21 March 2013 15:23, Judson Weissert <jud...@mfrac.com> wrote:
> It looks like osg::State already has that flag. See
> osg::State::_isVertexBufferObjectSupportResolved, and
> osg::State::isVertexBufferObjectSupported. Perhaps just the guard is
> missing?

I spotted this as well. I have added guards into the
osg::State::set*Pointer() methods and checked this into svn/trunk.
Attached is the modified include/osg/State.

Could you try it out.

> Thank you for looking into this. My OpenGL/OSG debugging skills are not
> quite where they need to be yet.

We all start with zero knowledge and progress from there. I've been
working on the OSG for over a decade (wow might even be 15 years now!)
and I'm still learning stuff about OpenGL/hardware/C++ and the even
OSG itself :-)

Robert.

[Judson Weissert]

Robert,

Excellent, I will begin testing it now and report back.

Thank you,

Judson

[Judson Weissert]

Robert,

I tested on VirtualBox (with and without 3D acceleration) and through Remote Desktop connection to the VirtualBox. The crash is gone for all permutations I tried!

I will continue to test, but the VBO fallback behavior and your fix appear to be working very well so far.

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.

Regards,

Judson

[Robert Osfield]

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.

[Garth D]

Hi Judson,

You're welcome. Happy to help.

Cheers,
Garth

[Judson Weissert]

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