Hi Stephan, On Wed, Jun 22, 2011 at 8:57 AM, Stephan Wenglorz <stephan.maku...@gmx.net> wrote: > my first post here :)
Welcome and thanks for pitching in with testing the release ;-) > OSG 3.0 RC2 in Release mode was built fine here on Debian Testing x86_64, > using g++ 4.6. I just got lots of warnings like > > warning: variable ‘xyz’ set but not used [-Wunused-but-set-variable]. I have g++ 4.5.2 and it doesn't support -Wunused-but-set-variable so can't review these warnings. They'll likely be all benign warnings so not critical to fix for 3.0.0. Could you post the full warnigns as text file so I can quickly look through them to see if there are any possible bugs that they might be highlighting? > (This type of warning is new in gcc 4.6) > I ran alot of the examples, which worked ok as far as I can tell, except > for: > > 1) osgmotionblur, which shows the model but logs this output to the console: > > Warning: detected OpenGL error 'invalid operation' at after > RenderBin::draw(..) This is because the ATI driver not yet support the accumulation buffer that the osgmotionblurr example uses. We can implement motion blurr using render to texture but the point of this example is to demonstate use of the accumulation buffer as much as motion blurr. A fix would probably be to see if we can automatically detect support for the accumulation buffer and then not run the viewer if it's not available. > 2) osgtexture2D, which, after some time of running ok, either aborts with > > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > > or with a segfault. This is will be a driver bug. It is frustruting that such a simple test app with simply GL usuage might fail though as it suggests that more problems would ensure in more complex GL usage. > GPU is an ATI HD4870 using the fglrx 11.4-2 driver. > Compiling the RC2 against GL3 worked flawlessly as well. Thanks for the testing. The AMD/ATI driver/functionality issues are something that AMD really need to look at. The warnings we can either ignore, fix or just suppress for the release. Fixing warnings might be preferrable if fixing them is a low risk to code portability and robustness - we do have to be careful about widespread warning "fixes" as it's easy to make mistakes and unintentially break code, one only needs to make 1 mistake in 100 warnings fixes for there to be a serious regression. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
