robertosfield wrote:
Hi Fred,
On Sat, May 28, 2011 at 1:18 PM, Fred Smith wrote:
On Windows XP or 7, AMD or nvidia hardware, they *are* causing a huge leak.
Ever head of driver problem??? Go try another OS, Go try another type
of hardware, Go try another driver, Go try a memory
Hi Fred,
On Sun, May 29, 2011 at 8:45 AM, Fred Smith osgfo...@tevs.eu wrote:
Ever head of driver problem??? Go try another OS, Go try another type
of hardware, Go try another driver, Go try a memory tracking tool.
Who are you going to convince this is a driver or OS problem here? Yourself?
robertosfield wrote:
...both of which are attached,
I run both tests :
fbotest --testRTT
And
fbotest
And both run without problems and without memory growth, there both
seem fine, despite be pretty dire ways to drive the OSG, both seem to
not cause any problems.
But they do.
Hi Fred,
On Sat, May 28, 2011 at 1:18 PM, Fred Smith osgfo...@tevs.eu wrote:
On Windows XP or 7, AMD or nvidia hardware, they *are* causing a huge leak.
Ever head of driver problem??? Go try another OS, Go try another type
of hardware, Go try another driver, Go try a memory tracking tool.
As
Hi,
Will this issue likely be addressed in the near future? I guess only somebody
relatively experienced with the OSG code base can dig into this.
I can test the code quite extensively as I have routines that process a lot of
data. Right now I'm stuck with release 2.9.10. Not absolutely sure
Hi Fred,
On Fri, May 27, 2011 at 1:12 PM, Fred Smith osgfo...@tevs.eu wrote:
Will this issue likely be addressed in the near future? I guess only somebody
relatively experienced with the OSG code base can dig into this.
I can test the code quite extensively as I have routines that process a
robertosfield wrote:
Hi Fred,
Please try the latest updates to svn/trunk, it may or may not address
the issues you have seen. If it doesn't please put together a small
example that reproduces the problem.
Robert.
robertosfield wrote:
Hi Fred,
On Fri, May 27, 2011 at 1:12 PM, Fred
Hi Fred,
On Fri, May 27, 2011 at 2:22 PM, Fred Smith osgfo...@tevs.eu wrote:
Run the modified osggeometry.cpp sample and look at the memory usage. There
is, apparently, a big memory leak. Increase the number of times
testRTTCamera() is called and you should see the leak even better.
The
Attached is a cleaned up, less messy version of the repro.
testRTTCamera() shows off the leak with offscreen rendering using a slave camera
testLeak() shows off the GraphicsContext leak.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39855#39855
this FBO issue will influence on QuadBuffer rendering?I got some quad buffer
problem...
...
Thank you!
Cheers,
Nan
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39857#39857
___
osg-users
Hi Nan,
On Fri, May 27, 2011 at 3:09 PM, Nan WANG nan.c...@gmail.com wrote:
this FBO issue will influence on QuadBuffer rendering?I got some quad buffer
problem...
QuadBuffer stereo is totally unrelated to FBO's.
Robert.
___
osg-users mailing list
Hi Fred,
On Fri, May 27, 2011 at 2:57 PM, Fred Smith osgfo...@tevs.eu wrote:
Attached is a cleaned up, less messy version of the repro.
testRTTCamera() shows off the leak with offscreen rendering using a slave
camera
testLeak() shows off the GraphicsContext leak.
The test code is still
Hi Fred,
sorry, I don't have time at the moment to check your code. I just
remember from past experience and bug reports to NVidia that OSG does
not reuse FBOs for new cameras, so it's quite possible one can run out
with the video driver complaining/crashing. The limits were also
different
Hi J.P.,
I'll try running osgmemorytest, but I don't have the problem with OSG 2.9.10.
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39526#39526
___
osg-users mailing list
OK, missed that it's a recent regression.
jp
On 19/05/11 09:26, Fred Smith wrote:
Hi J.P.,
I'll try running osgmemorytest, but I don't have the problem with OSG 2.9.10.
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39526#39526
Hi,
Here is a repro of the slave camera problem (the original problem, not the
bounding box stuff).
Increase the number of testRTTCamera() iterations to see the problem better.
It seems there is something wrong with respects to how GL objects are released,
as the program is stuck after a
Hi Robert,
I have a serious, massive memory leak in the trunk (updated this morning at
around 10am UK time). I haven't tried with previous releases yet.
The following code leaks memory in a very important manner. Put this code
within a while (true) { testLeak(); } block and you should see
Hi Robert,
I am a bit puzzled as the second problem I am having at the moment yields a
very different behavior when isolated out in a small repro.
This time I get an assertion.
Attached is a modified osggeometry.cpp file that triggers the assertion I'm
talking about. The assertion is raised
Same issues with OSG 2.9.10.
Any idea about what's going on?
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39466#39466
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Am 17.05.11 14:44, schrieb Fred Smith:
Hi Robert,
I am a bit puzzled as the second problem I am having at the moment yields a
very different behavior when isolated out in a small repro.
This time I get an assertion.
Attached is a modified osggeometry.cpp file that triggers the
Hi,
Thanks Stephan, you actually replied to my original message. I have since
edited it and suggested to concentrate on the leak issue. The other issue I
have is still under investigation and yes, the code I had originally posted
(too fast) to illustrate the second issue was incorrect ;)
Hi,
The second issue I had was that by design OSG doesn't assume the bounding box
of a drawable should be recalculated when setting a computeBoundingBoxCallback
up on the object.
In other words I was expecting Drawable::_boundingBoxComputed to be set back to
false when setting the callback.
robertosfield wrote:
Please try the latest updates to svn/trunk, it may or may not address
the issues you have seen. If it doesn't please put together a small
example that reproduces the problem.
I tried the trunk updated about an hour ago and I am still having problems. I
see the memory
Hi Paul,
I have step my step revert files from svn/trunk to the previous
versions in 2.9.10 and finally isolated the changes to
osgViewer/Renderer as being the causes of this regression.
There are number of changes that address different issues in
osgViewer::Renderer so I'll will need carefully
Hi Paul,
On Wed, Apr 20, 2011 at 10:48 AM, Robert Osfield
robert.osfi...@gmail.com wrote:
There are number of changes that address different issues in
osgViewer::Renderer so I'll will need carefully revert the changes to
pick out the cause of the problem. The difficulty in tracking down
this
Hi, Robert
I'm just curious, if this fix will resolve problems with freeing unused gl
texture objects (f.e. if you call dirtyTextureObject on texture attached to
camera and resize texture after that texture will create new gl texture object,
but old is still valid, and it not released on its
Hi,
I have an application using a single, unique viewer doing occasional RTT by the
means of an ABSOLUTE_RF slave camera with a distinct scene graph. I had chosen
a while ago to do my RTT this way and not use a separate context.
I have a tool that pregenerates lots of textures, each texture
Hi Sergey,
2011/4/20 Sergey Polischuk pol...@yandex.ru:
I'm just curious, if this fix will resolve problems with freeing unused gl
texture objects (f.e. if you call dirtyTextureObject on texture attached to
camera and resize texture after that texture will create new gl texture
object, but
Hi Fred,
Please try the latest updates to svn/trunk, it may or may not address
the issues you have seen. If it doesn't please put together a small
example that reproduces the problem.
Robert.
On Wed, Apr 20, 2011 at 3:25 PM, Fred Smith osgfo...@tevs.eu wrote:
Hi,
I have an application using
Hi, Robert
With svn/trunk all works like a charm. Great to see improvements :)
Cheers,
Sergey.
20.04.2011, 18:26, Robert Osfield robert.osfi...@gmail.com:
Hi Sergey,
2011/4/20 Sergey Polischuk pol...@yandex.ru;:
I'm just curious, if this fix will resolve problems with freeing unused gl
I've recently switched my application from 2.9.9 to 2.9.12 and now I'm having
FrameBufferObject problems (there seems to have been recent changes in this
area).
The problem can be replicated in osgprerender example with a few minor changes
(see attached). These changes simple recreate the
Maybe I should have added that I'm running on Linux with a Quadro FX 5800 video
card.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38601#38601
___
osg-users mailing list
Hi Paul,
I have just tried your modified osgprerender and can confirm that
problems exists on my system as well. I don't the cause of the
problem, my best guess right now would be something like inappropriate
reuse of GL objects.
Robert.
On Tue, Apr 19, 2011 at 3:39 PM, Paul Palumbo
Hi Paul,
On Tue, Apr 19, 2011 at 4:13 PM, Robert Osfield
robert.osfi...@gmail.com wrote:
I have just tried your modified osgprerender and can confirm that
problems exists on my system as well. I don't the cause of the
problem, my best guess right now would be something like inappropriate
34 matches
Mail list logo
