Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Cedric, osgViewer/core OSG should already have all the mechanisms available to do clean up of the scene graph and associated OpenGL objects correctly - and in fact it's possibly these existing mechanisms that are causing the failure in question. I suspect the solution will come from studying exactly what is happening and when during the destruction phases of the graphics threads, graphics context, scene graph and viewer, something small is likely amiss - the challenging is pinpointing exactly what this something small is... Once I've progressed the OpenGL ES 2.0 port a bit further I'll revisit this issue, my expectation is that it'll just require a couple of hours of TLC. Robert. On Sun, Oct 11, 2009 at 3:08 PM, Cedric Pinson cedric.pin...@plopbyte.net wrote: Hi Robert, I think to address the problem but i need to finish other stuff before. A way i thought to resolve that should be to add to osgViewer a cleanup method that would release all singleton and data that make it safe to quit an application. A method like that could be called automatically by osgViewer destructor or by hand maybe. It's not clear enough to me how the cleanup could be, but maybe it could be a way to clean the exit. Cheers, Cedric -- +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net On Sun, 2009-10-11 at 07:33 +0100, Robert Osfield wrote: Hi Cedric, As another lead into this problem I've found that the osgcatch example now hangs on exit when it's run multi-threaded. All the other examples exit fine, but osgcatch hangs inside th new TextureObject clean up code at a mutex that seems to be left locked by another thread. I don't know why this is, but clearly there is something fragile in the clean that will need addressing. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Cedric, As another lead into this problem I've found that the osgcatch example now hangs on exit when it's run multi-threaded. All the other examples exit fine, but osgcatch hangs inside th new TextureObject clean up code at a mutex that seems to be left locked by another thread. I don't know why this is, but clearly there is something fragile in the clean that will need addressing. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, I think to address the problem but i need to finish other stuff before. A way i thought to resolve that should be to add to osgViewer a cleanup method that would release all singleton and data that make it safe to quit an application. A method like that could be called automatically by osgViewer destructor or by hand maybe. It's not clear enough to me how the cleanup could be, but maybe it could be a way to clean the exit. Cheers, Cedric -- +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net On Sun, 2009-10-11 at 07:33 +0100, Robert Osfield wrote: Hi Cedric, As another lead into this problem I've found that the osgcatch example now hangs on exit when it's run multi-threaded. All the other examples exit fine, but osgcatch hangs inside th new TextureObject clean up code at a mutex that seems to be left locked by another thread. I don't know why this is, but clearly there is something fragile in the clean that will need addressing. Robert. signature.asc Description: This is a digitally signed message part ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
pankajnagarkoti80 wrote: The benefit the GL object pools provide is that we can scale up the scene graph in main memory without blowing OpenGL driver and GPU memory as we would do without the new pools. I agree, that is really a great benifit especially with the GL users. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18107#18107 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Cedric,
Thanks for keep on digging into this problem. I don't think this is a
bug in your code, rather you've just set up a set of circumstances
that the normal clean up is circumvented and an errors occurs. If
possible we should find a way of avoid the problem in full range of
usage.
Does the little example app you provided in your email reproduce the
crash on exit? Could we use this as a unit test?
Robert.
On Fri, Oct 9, 2009 at 1:49 PM, Cedric Pinson
cedric.pin...@plopbyte.net wrote:
Hi again,
ok i found my mistake and it could help other people that have a strange
behaviour when quitting. I make a small code to reproduce the problem.
At the end i did
myviewer.setSceneData(0);
in order to remove scene. With the new texture manager it produces this
valgrind output in attached file. I did not think it was bad to do that.
anyway if this post can save time for other people...
#include osg/ref_ptr
#include osgDB/ReadFile
#include osgDB/Registry
#include osgViewer/Viewer
#include osg/StateSet
#include osgText/Text
#include osg/Texture2D
int main(int argc, char** argv)
{
osg::ref_ptrosg::Group grp = new osg::Group;
osgViewer::Viewer myviewer;
myviewer.setSceneData(grp);
osg::ref_ptrosg::Geode geode = new osg::Geode;
osg::ref_ptrosgText::Text chipsText = new osgText::Text;
std::string fontName = ../data/Vera.ttf;
int size = 20;
osg::Vec3 pos(0,0,0);
osg::ref_ptrosgText::Font font =
osgText::readFontFile(fontName.c_str());
chipsText-setFont(font);
chipsText-setText(blabla);
geode-addDrawable(chipsText);
grp-addChild(geode);
myviewer.realize();
myviewer.run();
myviewer.setSceneData(0);
return 0;
}
--
+33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
http://www.plopbyte.net
On Thu, 2009-10-08 at 15:22 +0200, Cedric Pinson wrote:
Hi Robert,
I updated to the svn trunk today, and i can notice a crash when quitting
my application. To be sure it was with the new texture manager i defined
USE_NEW_TEXTURE_POOL to 0 and then to 1.
I dont have yet found the problem, but i guess it's linked with my
texture manager, i own some static that reference texture.
The segfault appear when quitting
Program received signal SIGSEGV, Segmentation fault.
#0 0xb6ef7ddf in ?? () from /lib/libc.so.6
#1 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
#2 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
#3 0xb54f2008 in ?? ()
#4 0xb54f2008 in ?? ()
#5 0xb6193d60 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
#6 0xb6fd0bcb in ?? () from /lib/libc.so.6
#7 0xb6fd26e8 in ?? () from /lib/libc.so.6
#8 0xb6fcf469 in ?? () from /lib/libc.so.6
#9 0xb6fcf442 in ?? () from /lib/libc.so.6
#10 0xbfc68254 in ?? ()
#11 0xa7200010 in ?? ()
#12 0x001d in ?? ()
#13 0x in ?? ()
I guess there is something wrong with my texture management and the new
texture pool.
I continue to dig
Cheers,
Cedric
--
+33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
http://www.plopbyte.net
On Fri, 2009-10-02 at 22:21 +0100, Robert Osfield wrote:
Hi All,
I've been pretty quiet and the public list/forum through September,
keeping my head down developing new functionality for the OSG... and
the new functionality I'm pleased to announce today is that we now
have a loverly new back-end implementation for texture objects and
buffer objects (VertexBufferObject, ElementBufferObjects and
PixelBufferObjects's) that provides a set of GL objects pools that
enable recycling of both orphaned GL objects and reuse of GL objects
that are still attached to the scene graph, but are stale - i.e.
haven't been rendered in the last frame.
The benefit the GL object pools provide is that we can scale up the
scene graph in main memory without blowing OpenGL driver and GPU
memory as we would do without the new pools. This feature also
reduces the likely-hood of thrashing of OpenGL driver and GPU memory
so that where we might have previously seen frame drops due to memory
management we avoid them completely or reduce there impact. The
memory pools will come in there own once we scale down the GPU memory
size, such as embedded systems, or on desktop/workstation applications
where GPU memory can be overflowed due to massive databases being kept
in main memory. In the later case this issue is more compounded on
some OS's, such as Vista, that limits the amount of memory that OpenGL
drivers can allocate, so here it should help make the app more stable
(avoid the crashes due to out of memory errors) and faster.
So... how to try out the new texture and buffer object pools? First
up you'll need to update to the latest OpenScenGraph svn/trunk. Next
you'll need to enable the pools by setting the env vars: (example
below for bash)
export OSG_TEXTURE_POOL_SIZE=1 // size in bytes (100Mb)
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert,
Yes you will be able to reproduce the valgrind output with the the code
sample in the email.
Cheers,
Cedric
--
+33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
http://www.plopbyte.net
On Fri, 2009-10-09 at 14:24 +0100, Robert Osfield wrote:
Hi Cedric,
Thanks for keep on digging into this problem. I don't think this is a
bug in your code, rather you've just set up a set of circumstances
that the normal clean up is circumvented and an errors occurs. If
possible we should find a way of avoid the problem in full range of
usage.
Does the little example app you provided in your email reproduce the
crash on exit? Could we use this as a unit test?
Robert.
On Fri, Oct 9, 2009 at 1:49 PM, Cedric Pinson
cedric.pin...@plopbyte.net wrote:
Hi again,
ok i found my mistake and it could help other people that have a strange
behaviour when quitting. I make a small code to reproduce the problem.
At the end i did
myviewer.setSceneData(0);
in order to remove scene. With the new texture manager it produces this
valgrind output in attached file. I did not think it was bad to do that.
anyway if this post can save time for other people...
#include osg/ref_ptr
#include osgDB/ReadFile
#include osgDB/Registry
#include osgViewer/Viewer
#include osg/StateSet
#include osgText/Text
#include osg/Texture2D
int main(int argc, char** argv)
{
osg::ref_ptrosg::Group grp = new osg::Group;
osgViewer::Viewer myviewer;
myviewer.setSceneData(grp);
osg::ref_ptrosg::Geode geode = new osg::Geode;
osg::ref_ptrosgText::Text chipsText = new osgText::Text;
std::string fontName = ../data/Vera.ttf;
int size = 20;
osg::Vec3 pos(0,0,0);
osg::ref_ptrosgText::Font font =
osgText::readFontFile(fontName.c_str());
chipsText-setFont(font);
chipsText-setText(blabla);
geode-addDrawable(chipsText);
grp-addChild(geode);
myviewer.realize();
myviewer.run();
myviewer.setSceneData(0);
return 0;
}
--
+33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
http://www.plopbyte.net
On Thu, 2009-10-08 at 15:22 +0200, Cedric Pinson wrote:
Hi Robert,
I updated to the svn trunk today, and i can notice a crash when quitting
my application. To be sure it was with the new texture manager i defined
USE_NEW_TEXTURE_POOL to 0 and then to 1.
I dont have yet found the problem, but i guess it's linked with my
texture manager, i own some static that reference texture.
The segfault appear when quitting
Program received signal SIGSEGV, Segmentation fault.
#0 0xb6ef7ddf in ?? () from /lib/libc.so.6
#1 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
#2 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
#3 0xb54f2008 in ?? ()
#4 0xb54f2008 in ?? ()
#5 0xb6193d60 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
#6 0xb6fd0bcb in ?? () from /lib/libc.so.6
#7 0xb6fd26e8 in ?? () from /lib/libc.so.6
#8 0xb6fcf469 in ?? () from /lib/libc.so.6
#9 0xb6fcf442 in ?? () from /lib/libc.so.6
#10 0xbfc68254 in ?? ()
#11 0xa7200010 in ?? ()
#12 0x001d in ?? ()
#13 0x in ?? ()
I guess there is something wrong with my texture management and the new
texture pool.
I continue to dig
Cheers,
Cedric
--
+33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
http://www.plopbyte.net
On Fri, 2009-10-02 at 22:21 +0100, Robert Osfield wrote:
Hi All,
I've been pretty quiet and the public list/forum through September,
keeping my head down developing new functionality for the OSG... and
the new functionality I'm pleased to announce today is that we now
have a loverly new back-end implementation for texture objects and
buffer objects (VertexBufferObject, ElementBufferObjects and
PixelBufferObjects's) that provides a set of GL objects pools that
enable recycling of both orphaned GL objects and reuse of GL objects
that are still attached to the scene graph, but are stale - i.e.
haven't been rendered in the last frame.
The benefit the GL object pools provide is that we can scale up the
scene graph in main memory without blowing OpenGL driver and GPU
memory as we would do without the new pools. This feature also
reduces the likely-hood of thrashing of OpenGL driver and GPU memory
so that where we might have previously seen frame drops due to memory
management we avoid them completely or reduce there impact. The
memory pools will come in there own once we scale down the GPU memory
size, such as embedded systems, or on desktop/workstation applications
where GPU memory can be overflowed due to massive databases being kept
in main memory. In the later case this issue is more compounded on
some OS's, such as Vista, that limits the amount of memory that OpenGL
drivers can allocate, so here
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, I updated to the svn trunk today, and i can notice a crash when quitting my application. To be sure it was with the new texture manager i defined USE_NEW_TEXTURE_POOL to 0 and then to 1. I dont have yet found the problem, but i guess it's linked with my texture manager, i own some static that reference texture. The segfault appear when quitting Program received signal SIGSEGV, Segmentation fault. #0 0xb6ef7ddf in ?? () from /lib/libc.so.6 #1 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1 #2 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1 #3 0xb54f2008 in ?? () #4 0xb54f2008 in ?? () #5 0xb6193d60 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1 #6 0xb6fd0bcb in ?? () from /lib/libc.so.6 #7 0xb6fd26e8 in ?? () from /lib/libc.so.6 #8 0xb6fcf469 in ?? () from /lib/libc.so.6 #9 0xb6fcf442 in ?? () from /lib/libc.so.6 #10 0xbfc68254 in ?? () #11 0xa7200010 in ?? () #12 0x001d in ?? () #13 0x in ?? () I guess there is something wrong with my texture management and the new texture pool. I continue to dig Cheers, Cedric -- +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net On Fri, 2009-10-02 at 22:21 +0100, Robert Osfield wrote: Hi All, I've been pretty quiet and the public list/forum through September, keeping my head down developing new functionality for the OSG... and the new functionality I'm pleased to announce today is that we now have a loverly new back-end implementation for texture objects and buffer objects (VertexBufferObject, ElementBufferObjects and PixelBufferObjects's) that provides a set of GL objects pools that enable recycling of both orphaned GL objects and reuse of GL objects that are still attached to the scene graph, but are stale - i.e. haven't been rendered in the last frame. The benefit the GL object pools provide is that we can scale up the scene graph in main memory without blowing OpenGL driver and GPU memory as we would do without the new pools. This feature also reduces the likely-hood of thrashing of OpenGL driver and GPU memory so that where we might have previously seen frame drops due to memory management we avoid them completely or reduce there impact. The memory pools will come in there own once we scale down the GPU memory size, such as embedded systems, or on desktop/workstation applications where GPU memory can be overflowed due to massive databases being kept in main memory. In the later case this issue is more compounded on some OS's, such as Vista, that limits the amount of memory that OpenGL drivers can allocate, so here it should help make the app more stable (avoid the crashes due to out of memory errors) and faster. So... how to try out the new texture and buffer object pools? First up you'll need to update to the latest OpenScenGraph svn/trunk. Next you'll need to enable the pools by setting the env vars: (example below for bash) export OSG_TEXTURE_POOL_SIZE=1 // size in bytes (100Mb) export OSG_BUFFER_OBJECT_POOL_SIZE=2 // size in bytes (200Mb) Then run your app with some big data, such a large paged database, you can push the amount of main memory used by enabling the MaxPagedLOD feature in the DatabasePager via: export OSG_MAX_PAGEDLOD=10 // keep in memory a maximum of 100,000 PagedLOD nodes You can also set these values programmatically via osg::DisplaySettings. A word of warning though, I have almost completely rewritten the way that the backend that drives texture objects and buffer objects, even when you don't enable the texture/buffer object pools, the code managing the GL objects is still completely different. With major changes like this comes the likelihood of regressions. I've been doing a range of tests at my end, but it's still far more limited in scope to what the community will expose the OSG to, so... there you may way see problems that I haven't. The best I can do is endeavor to get them fixed as quickly as possible, just let me know if you see something odd and I we can work together to spot what the underlying problem and squish it. The more testing we can get the quicker we can shape the code up to being release quality. Have fun with it :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org signature.asc Description: This is a digitally signed message part ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, I cleaned all my singleton before quitting the application. Now i have the following crash but sometimes it's random. It seems the TextureObjectManager is deleted before the cache is cleared by Registry destructor and produce a crash somewhere. I am a bit confuse now, i continue to track it. Just for info i use the cache of the registry... #0 0x081290a8 in ScopedLock (this=0xbf8132b4, m...@0x82d2004) at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/OpenThreads/ScopedLock:31 #1 0xb7f87645 in osg::Texture::TextureObjectSet::orphan (this=0x82d1ff8, to=0x892a078) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:558 #2 0xb7f87723 in osg::Texture::TextureObjectManager::releaseTextureObject (this=0xa594ed90, to=0x892a078) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:736 #3 0xb7f87796 in osg::Texture::releaseTextureObject (contextID=0, to=0x892a078) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:819 #4 0xb7f8780a in osg::Texture::dirtyTextureObject (this=0xb3af02d8) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:1298 #5 0xb7f87b73 in ~Texture (this=0xb3af02d8) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:1186 #6 0xb7f7cc2f in ~Texture2D (this=0xb3af02d8) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture2D.cpp:52 #7 0x0810f6a2 in osg::Referenced::unref (this=0xb3af02d8) at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/Referenced:183 #8 0x0813434c in ~ref_ptr (this=0xb3af0994) at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/ref_ptr:33 #9 0x0813436c in ~pair (this=0xb3af0990) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_pair.h:73 #10 0x0813437f in __gnu_cxx::new_allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::destroy (this=0xbf81343f, __p=0xb3af0990) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/ext/new_allocator.h:118 #11 0x081343b4 in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_destroy_node (this=0xb4a0a078, __p=0xb3af0980) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:390 #12 0x0813443e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb3af0980) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:943 #13 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb3af0a40) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #14 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb3af0a20) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #15 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb3af0a60) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #16 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb4a09ea0) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #17 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb4a09e80) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #18 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb4a006b8) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #19 0x0813446e in ~_Rb_tree (this=0xb4a0a078) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:585 #20 0x081344c1 in ~map (this=0xb4a0a078) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/bits/stl_map.h:92 #21 0x08134cff in ~DeckNode (this=0xb4a09ff8) at
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, What results do you get with the bug fixes I've just checked in? I've just updated and now I get a single corrupted image flashed onto the screen and then a segfault. $ osgmovie --mouse --interactive --shaders -e ffmpeg file.avi image-s()640 image-t()=480 aspectRatio=1 _maxTexturePoolSize=0 _maxBufferObjectPoolSize=0 Created new TextureObject, _numOfTextureObjects 1 GLBufferObjectSet::GLBufferObjectSet _profile._size=1228800 Segmentation fault If I run in gdb the corrupted image stays, but I'll have to recompile with debug info to give you a more sensible backtrace. Tomorrow... have to go now. Debug build still did not provide a nice backtrace, but I've followed the crash to void TextureRectangle::applyTexImage_subload in TextureRectangle.cpp At the line: dataPtr = reinterpret_castunsigned char*(pbo-getOffset(image-getBufferIndex())); dataPtr gets assigned 0 and then the glTexSubImage2D call generates the segfault. jp -- 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi J.P, On Wed, Oct 7, 2009 at 7:59 AM, J.P. Delport jpdelp...@csir.co.za wrote: Debug build still did not provide a nice backtrace, but I've followed the crash to void TextureRectangle::applyTexImage_subload in TextureRectangle.cpp At the line: dataPtr = reinterpret_castunsigned char*(pbo-getOffset(image-getBufferIndex())); dataPtr gets assigned 0 and then the glTexSubImage2D call generates the segfault. It's normal for pbo-getOffset() to return a 0, and correct to pass this to glTexSubImage2D, but only if a PBO is bound, if it isn't then it will result in a seg fault. Perhaps there is some mistake in the code that isn't binding the PBO when it should. Do you get a crash if you use the --texture2D on the osgmovie command line? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, Robert Osfield wrote: Hi J.P, On Wed, Oct 7, 2009 at 7:59 AM, J.P. Delport jpdelp...@csir.co.za wrote: Debug build still did not provide a nice backtrace, but I've followed the crash to void TextureRectangle::applyTexImage_subload in TextureRectangle.cpp At the line: dataPtr = reinterpret_castunsigned char*(pbo-getOffset(image-getBufferIndex())); dataPtr gets assigned 0 and then the glTexSubImage2D call generates the segfault. It's normal for pbo-getOffset() to return a 0, and correct to pass this to glTexSubImage2D, but only if a PBO is bound, if it isn't then it will result in a seg fault. Perhaps there is some mistake in the code that isn't binding the PBO when it should. OK, I'll try to check this too. Do you get a crash if you use the --texture2D on the osgmovie command line? No, it runs, but with Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) after every frame. 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi J.P., What hardware and OS are you testing on right now? On Wed, Oct 7, 2009 at 10:36 AM, J.P. Delport jpdelp...@csir.co.za wrote: It's normal for pbo-getOffset() to return a 0, and correct to pass this to glTexSubImage2D, but only if a PBO is bound, if it isn't then it will result in a seg fault. Perhaps there is some mistake in the code that isn't binding the PBO when it should. OK, I'll try to check this too. I've just done a code review of TextureRectangle.cpp code and it looks to be binding the PBO and setting the data pointer appropriately. I'm afraid I haven't yet spotted any lead of what to look into next. Do you get a crash if you use the --texture2D on the osgmovie command line? No, it runs, but with Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) after every frame. I upped the granularity of GL error checked via: export OSG_GL_ERROR_CHECKING=ONCE_PER_ATTRIBUTE And it then generated the warning after the texture apply, still an invalid enumerant. Add more fine grained checks into osg::Texture, Texture2D and TextureRectangle to further isolate which gl call is the problem is probably required. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi, It's normal for pbo-getOffset() to return a 0, and correct to pass this to glTexSubImage2D, but only if a PBO is bound, if it isn't then it will result in a seg fault. Perhaps there is some mistake in the code that isn't binding the PBO when it should. OK, I'll try to check this too. Do you get a crash if you use the --texture2D on the osgmovie command line? No, it runs, but with Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) after every frame. just some more comments... I've compared code for Texture::applyTexImage2D_subload vs TextureRectangle::applyTexImage_subload in the former the result of pbo-getOffset() is never used. If in TextureRectangle::applyTexImage_subload I leave dataPtr to point to the image data, it runs the same as --texture2D, i.e. Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) after every frame. jp -- 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi J.P, On Wed, Oct 7, 2009 at 11:26 AM, J.P. Delport jpdelp...@csir.co.za wrote: just some more comments... I've compared code for Texture::applyTexImage2D_subload vs TextureRectangle::applyTexImage_subload in the former the result of pbo-getOffset() is never used. If in TextureRectangle::applyTexImage_subload I leave dataPtr to point to the image data, it runs the same as --texture2D, i.e. Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) Could you pinpoint the code you are referring to? Copying and pasting into an email would be fine, or even line numbers might be OK if you are working against svn/trunk. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, Robert Osfield wrote: Hi J.P., What hardware and OS are you testing on right now? Debian 32-bit, Nvidia driver. On Wed, Oct 7, 2009 at 10:36 AM, J.P. Delport jpdelp...@csir.co.za wrote: It's normal for pbo-getOffset() to return a 0, and correct to pass this to glTexSubImage2D, but only if a PBO is bound, if it isn't then it will result in a seg fault. Perhaps there is some mistake in the code that isn't binding the PBO when it should. OK, I'll try to check this too. I've just done a code review of TextureRectangle.cpp code and it looks to be binding the PBO and setting the data pointer appropriately. I'm afraid I haven't yet spotted any lead of what to look into next. Found it. Typo/copypasted line in PBO constructor. Target was set to wrong value and that made the bind fail. Modded file attached. TextureRectangle now works fine in osgmovie. The world feels better :) jp -- 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. MailScanner thanks Transtec Computers for their support. BufferObject.cpp.gz Description: GNU Zip compressed data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert,
Robert Osfield wrote:
Hi J.P,
On Wed, Oct 7, 2009 at 11:26 AM, J.P. Delport jpdelp...@csir.co.za wrote:
just some more comments...
I've compared code for
Texture::applyTexImage2D_subload
vs
TextureRectangle::applyTexImage_subload
in the former the result of pbo-getOffset() is never used.
If in TextureRectangle::applyTexImage_subload I leave dataPtr to point to
the image data, it runs the same as --texture2D, i.e.
Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,)
Could you pinpoint the code you are referring to? Copying and pasting
into an email would be fine, or even line numbers might be OK if you
are working against svn/trunk.
In Texture::applyTexImage2D_subload Texture.cpp line 2064
glTexSubImage2D( target, 0,
0, 0,
inwidth, inheight,
(GLenum)image-getPixelFormat(),
(GLenum)image-getDataType(),
data - dataMinusOffset + dataPlusOffset);
is called with data
line 1987
unsigned char* data = (unsigned char*)image-data();
line 2035, still same function...
const unsigned char* dataPtr = image-data();
GLBufferObject* pbo = image-getOrCreateGLBufferObject(contextID);
if (pbo !needImageRescale !useGluBuildMipMaps)
{
state.bindPixelBufferObject(pbo);
dataPtr = reinterpret_castunsigned
char*(pbo-getOffset(image-getBufferIndex()));
dataPtr is set here, but not used at all further in the function.
If you compare this with TextureRectangle::applyTexImage_subload you
will see that dataPtr is set and used there.
So, osgmovie --texture2D now still gives corrupted images, even with the
BufferObject fix applied. It used to work because the binding failed.
Hope I explained better.
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. MailScanner thanks Transtec Computers for their support.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, Robert Osfield wrote: A word of warning though, I have almost completely rewritten the way that the backend that drives texture objects and buffer objects, even when you don't enable the texture/buffer object pools, the code managing the GL objects is still completely different. With major changes like this comes the likelihood of regressions. I've been doing a range of tests at my end, but it's still far more limited in scope to what the community will expose the OSG to, so... there you may way see problems that I haven't. The best I can do is endeavor to get them fixed as quickly as possible, just let me know if you see something odd and I we can work together to spot what the underlying problem and squish it. The more testing we can get the quicker we can shape the code up to being release quality. I have problems with PBOs since updating to the latest svn. I'm not setting any pool env variables. One can recreate the problem with osgmovie. E.g. $ osgmovie --mouse --interactive --shaders -e ffmpeg file.avi _maxTexturePoolSize=0 _maxBufferObjectPoolSize=0 GLBufferObjectSet::GLBufferObjectSet _profile._size=1228800 Error numInList + _orphanedTextureObjects.size() != _numOfTextureObjects numInList = 1 _orphanedTextureObjects.size() = 0 _pendingOrphanedTextureObjects.size() = 0 _numOfTextureObjects = 0 terminate called after throwing an instance of 'char const*' Aborted Can you confirm if this happens on your side too? jp Have fun with it :-) 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
The benefit the GL object pools provide is that we can scale up the scene graph in main memory without blowing OpenGL driver and GPU memory as we would do without the new pools. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17920#17920 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
HI J.P., On Tue, Oct 6, 2009 at 8:26 AM, J.P. Delport jpdelp...@csir.co.za wrote: I have problems with PBOs since updating to the latest svn. I'm not setting any pool env variables. One can recreate the problem with osgmovie. E.g. $ osgmovie --mouse --interactive --shaders -e ffmpeg file.avi _maxTexturePoolSize=0 _maxBufferObjectPoolSize=0 GLBufferObjectSet::GLBufferObjectSet _profile._size=1228800 Error numInList + _orphanedTextureObjects.size() != _numOfTextureObjects numInList = 1 _orphanedTextureObjects.size() = 0 _pendingOrphanedTextureObjects.size() = 0 _numOfTextureObjects = 0 terminate called after throwing an instance of 'char const*' Aborted Can you confirm if this happens on your side too? Just tested this and I can confirm it happens for me too. I did have this working as it was one of the elements I first tested, but alas there has clearly been a regression as I completed the rest of the task. I will investigate what had gone a miss. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi J.P. On Tue, Oct 6, 2009 at 9:01 AM, Robert Osfield robert.osfi...@gmail.com wrote: Just tested this and I can confirm it happens for me too. I did have this working as it was one of the elements I first tested, but alas there has clearly been a regression as I completed the rest of the task. I will investigate what had gone a miss. I have now tracked down the problem to a bug in the reassignment of TextureObject to a new TextureObjectSet, this is now fixed along with a couple of other bugs due to the unrefAfterApply not being disabled when the texture pool is enabled. These fixes are now checked into svn/trunk. I am currently seeing GL errors reported when running osgmovie of the form: Warning: detected OpenGL error 'invalid enumerant' after applying attribute TextureRectangle 0x1fdb4e0 With the onscreen image being corrupted, while if I select a Texture2D using the osgmovie command line option --texture2D I get: Warning: detected OpenGL error 'invalid enumerant' after applying attribute Texture2D 0x1c724e0 But the onscreen image is correct. If comment out the assignment of the PixelBufferObject in the ImageStream constructor the on screen errors and the console warnings all disappear so it looks to be a PBO issue of some kind. I've only tried out this on my ATI card so far so it could be driver issue. What results do you get with the bug fixes I've just checked in? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, Robert Osfield wrote: I will investigate what had gone a miss. I have now tracked down the problem to a bug in the reassignment of TextureObject to a new TextureObjectSet, this is now fixed along with a couple of other bugs due to the unrefAfterApply not being disabled when the texture pool is enabled. These fixes are now checked into svn/trunk. I am currently seeing GL errors reported when running osgmovie of the form: Warning: detected OpenGL error 'invalid enumerant' after applying attribute TextureRectangle 0x1fdb4e0 With the onscreen image being corrupted, while if I select a Texture2D using the osgmovie command line option --texture2D I get: Warning: detected OpenGL error 'invalid enumerant' after applying attribute Texture2D 0x1c724e0 But the onscreen image is correct. If comment out the assignment of the PixelBufferObject in the ImageStream constructor the on screen errors and the console warnings all disappear so it looks to be a PBO issue of some kind. I've only tried out this on my ATI card so far so it could be driver issue. What results do you get with the bug fixes I've just checked in? I've just updated and now I get a single corrupted image flashed onto the screen and then a segfault. $ osgmovie --mouse --interactive --shaders -e ffmpeg file.avi image-s()640 image-t()=480 aspectRatio=1 _maxTexturePoolSize=0 _maxBufferObjectPoolSize=0 Created new TextureObject, _numOfTextureObjects 1 GLBufferObjectSet::GLBufferObjectSet _profile._size=1228800 Segmentation fault If I run in gdb the corrupted image stays, but I'll have to recompile with debug info to give you a more sensible backtrace. Tomorrow... have to go now. jp ---8--- Created new TextureObject, _numOfTextureObjects 1 GLBufferObjectSet::GLBufferObjectSet _profile._size=1228800 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb2952b90 (LWP 22742)] 0xb6d69e60 in ?? () from /usr/lib/libGLcore.so.1 (gdb) bt #0 0xb6d69e60 in ?? () from /usr/lib/libGLcore.so.1 Cannot access memory at address 0xa04 (gdb) thread [Current thread is 5 (Thread 0xb2952b90 (LWP 22742))] (gdb) info threads * 5 Thread 0xb2952b90 (LWP 22742) 0xb6d69e60 in ?? () from /usr/lib/libGLcore.so.1 4 Thread 0xb3c81b90 (LWP 22741) 0xb7fe1424 in __kernel_vsyscall () 3 Thread 0xb4482b90 (LWP 22740) 0xb7fe1424 in __kernel_vsyscall () 2 Thread 0xb4c83b90 (LWP 22739) 0xb7fe1424 in __kernel_vsyscall () 1 Thread 0xb62a8950 (LWP 22736) 0xb7fe1424 in __kernel_vsyscall () 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Thanks for the testing and pinpointing of the error. I've added an OSG_EXPORT to BufferData and checked this in. BufferObjectProfile won't need an export at it's a class entirely defined in the header. Cheers, Robert. On Sat, Oct 3, 2009 at 4:35 PM, Tony Horrobin tony.horro...@gmail.com wrote: Hi Robert, On Vista SP2 with Visual C++ 2005: osgparametric fails with unresolved symbol osg::BufferData::setBufferObject(class osg::BufferObject *) I believe this is due to missing OSG_EXPORT for BufferData in osg/BufferObject. BufferObjectProfile is also missing OSG_EXPORT but this doesn't appear to cause problems at the moment. Recompiling now. Cheers, Tony -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17835#17835 ___ 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] New OpenGL texture object and buffer object pool support
Hi All, On Fri, Oct 2, 2009 at 10:24 PM, Robert Osfield robert.osfi...@gmail.com wrote: You'll need to wait, my attempt to check changes in has failed due to problems connecting to the server.. I'll ping the list once things are successfully checked in. Changes now checked in. For majority of users no code changes in your application should be required as it's principally the backend that's changed radically, but for a small number of users that dig down to lower level management of buffer objects/texture objects you may need to adapt your code. Fingers crossed that it won't break the build, or runtime Please test throughly and let me know how you get on. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, Some errors on my WindowsXP SP2 + VS2008 while building SceneView.cpp. Modify the code at line 1028: osg::GLBufferObjectManager::GLBufferObjectManager* bom = osg::GLBufferObjectManager::getGLBufferObjectManager(state-getContextID()); to: osg::GLBufferObjectManager* bom = osg::GLBufferObjectManager::getGLBufferObjectManager(state-getContextID()); And it builds well. I will help test the exciting new texture pool functionality with my 80GB Tibet buildings data after the Chinese National Day holidays. :) Wang Rui 2009/10/3 Robert Osfield robert.osfi...@gmail.com Hi All, On Fri, Oct 2, 2009 at 10:24 PM, Robert Osfield robert.osfi...@gmail.com wrote: You'll need to wait, my attempt to check changes in has failed due to problems connecting to the server.. I'll ping the list once things are successfully checked in. Changes now checked in. For majority of users no code changes in your application should be required as it's principally the backend that's changed radically, but for a small number of users that dig down to lower level management of buffer objects/texture objects you may need to adapt your code. Fingers crossed that it won't break the build, or runtime Please test throughly and let me know how you get on. Cheers, Robert. ___ 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] New OpenGL texture object and buffer object pool support
Hi Robert -- Current svn builds OK on OSX, but osgDB::ReadNodeFile is coming up as an undefined symbol when I try to build any of my own code. Note that the OSG examples all appear to build fine. So this is an odd one. Windows build is underway. I'll look into this further and let you know if I find anything. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Thanks Wang Rui, I've made your suggestion change and checked in into svn/trunk. Cheers, Robert. On Sat, Oct 3, 2009 at 2:40 PM, Wang Rui wangra...@gmail.com wrote: Hi Robert, Some errors on my WindowsXP SP2 + VS2008 while building SceneView.cpp. Modify the code at line 1028: osg::GLBufferObjectManager::GLBufferObjectManager* bom = osg::GLBufferObjectManager::getGLBufferObjectManager(state-getContextID()); to: osg::GLBufferObjectManager* bom = osg::GLBufferObjectManager::getGLBufferObjectManager(state-getContextID()); And it builds well. I will help test the exciting new texture pool functionality with my 80GB Tibet buildings data after the Chinese National Day holidays. :) Wang Rui 2009/10/3 Robert Osfield robert.osfi...@gmail.com Hi All, On Fri, Oct 2, 2009 at 10:24 PM, Robert Osfield robert.osfi...@gmail.com wrote: You'll need to wait, my attempt to check changes in has failed due to problems connecting to the server.. I'll ping the list once things are successfully checked in. Changes now checked in. For majority of users no code changes in your application should be required as it's principally the backend that's changed radically, but for a small number of users that dig down to lower level management of buffer objects/texture objects you may need to adapt your code. Fingers crossed that it won't break the build, or runtime Please test throughly and let me know how you get on. Cheers, Robert. ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Paul, On Sat, Oct 3, 2009 at 3:17 PM, Paul Martz pma...@skew-matrix.com wrote: Hi Robert -- Current svn builds OK on OSX, but osgDB::ReadNodeFile is coming up as an undefined symbol when I try to build any of my own code. Note that the OSG examples all appear to build fine. So this is an odd one. I haven't made any changes to osgDB::readNodeFile, is there a chance that a build error elsewhere has caused osgDB to not build and link properly? Windows build is underway. You'll need the change suggested by Wang Rui, this is now checked into svn/trunk so an update should get you on your way. I'll look into this further and let you know if I find anything. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, On Vista SP2 with Visual C++ 2005: osgparametric fails with unresolved symbol osg::BufferData::setBufferObject(class osg::BufferObject *) I believe this is due to missing OSG_EXPORT for BufferData in osg/BufferObject. BufferObjectProfile is also missing OSG_EXPORT but this doesn't appear to cause problems at the moment. Recompiling now. Cheers, Tony -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17835#17835 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Robert Osfield wrote: On Sat, Oct 3, 2009 at 3:17 PM, Paul Martz pma...@skew-matrix.com wrote: Hi Robert -- Current svn builds OK on OSX, but osgDB::ReadNodeFile is coming up as an undefined symbol when I try to build any of my own code. Note that the OSG examples all appear to build fine. So this is an odd one. I haven't made any changes to osgDB::readNodeFile, is there a chance that a build error elsewhere has caused osgDB to not build and link properly? Yeah, I suspected I had some kind of build inconsistency too, it just didn't smell like it was related to your changes. Indeed this was the case. After cleaning out several accumulated installs and rebuilding, everything is fine with current svn on OSX, as near as I can tell. Thanks. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Tony Horrobin wrote: Hi Robert, On Vista SP2 with Visual C++ 2005: osgparametric fails with unresolved symbol osg::BufferData::setBufferObject(class osg::BufferObject *) I saw this on OSX as well, buried in amongst all the readNodeFile calls that came up undefined. This was a bad build and install on my system. Cleaning things out and rebuilding resolved both issues. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] New OpenGL texture object and buffer object pool support
Hi All, I've been pretty quiet and the public list/forum through September, keeping my head down developing new functionality for the OSG... and the new functionality I'm pleased to announce today is that we now have a loverly new back-end implementation for texture objects and buffer objects (VertexBufferObject, ElementBufferObjects and PixelBufferObjects's) that provides a set of GL objects pools that enable recycling of both orphaned GL objects and reuse of GL objects that are still attached to the scene graph, but are stale - i.e. haven't been rendered in the last frame. The benefit the GL object pools provide is that we can scale up the scene graph in main memory without blowing OpenGL driver and GPU memory as we would do without the new pools. This feature also reduces the likely-hood of thrashing of OpenGL driver and GPU memory so that where we might have previously seen frame drops due to memory management we avoid them completely or reduce there impact. The memory pools will come in there own once we scale down the GPU memory size, such as embedded systems, or on desktop/workstation applications where GPU memory can be overflowed due to massive databases being kept in main memory. In the later case this issue is more compounded on some OS's, such as Vista, that limits the amount of memory that OpenGL drivers can allocate, so here it should help make the app more stable (avoid the crashes due to out of memory errors) and faster. So... how to try out the new texture and buffer object pools? First up you'll need to update to the latest OpenScenGraph svn/trunk. Next you'll need to enable the pools by setting the env vars: (example below for bash) export OSG_TEXTURE_POOL_SIZE=1 // size in bytes (100Mb) export OSG_BUFFER_OBJECT_POOL_SIZE=2 // size in bytes (200Mb) Then run your app with some big data, such a large paged database, you can push the amount of main memory used by enabling the MaxPagedLOD feature in the DatabasePager via: export OSG_MAX_PAGEDLOD=10 // keep in memory a maximum of 100,000 PagedLOD nodes You can also set these values programmatically via osg::DisplaySettings. A word of warning though, I have almost completely rewritten the way that the backend that drives texture objects and buffer objects, even when you don't enable the texture/buffer object pools, the code managing the GL objects is still completely different. With major changes like this comes the likelihood of regressions. I've been doing a range of tests at my end, but it's still far more limited in scope to what the community will expose the OSG to, so... there you may way see problems that I haven't. The best I can do is endeavor to get them fixed as quickly as possible, just let me know if you see something odd and I we can work together to spot what the underlying problem and squish it. The more testing we can get the quicker we can shape the code up to being release quality. Have fun with it :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
So... how to try out the new texture and buffer object pools? First up you'll need to update to the latest OpenScenGraph svn/trunk. You'll need to wait, my attempt to check changes in has failed due to problems connecting to the server.. I'll ping the list once things are successfully checked in. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
