Hi Robert,
I tested a few of our scene's and till now there are no problems.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61638#61638
___
osg-users mailing list
Due to some other work I won't be able to test this out today, but I'll try to
make room for it tomorrow.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61614#61614
___
osg-users
I have done some tests and it looks good so far. There is only one regression
here and that is that proxy nodes that are set to load immediately are never
looked up from the cache ever. This actually is the most common use case for us
for those types of nodes.
In our program we by chance had
Hi Pjotr,
On 11 November 2014 09:54, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
I have done some tests and it looks good so far. There is only one
regression here and that is that proxy nodes that are set to load
immediately are never looked up from the cache ever. This actually is the
Hi Pjotr,
On 11 November 2014 10:30, Robert Osfield robert.osfi...@gmail.com wrote:
On 11 November 2014 09:54, Pjotr Svetachov pjotrsvetac...@gmail.com
wrote:
I have done some tests and it looks good so far. There is only one
regression here and that is that proxy nodes that are set to load
That sounds good. You might even want to have a mapfilename, Readresult
somewhere in there, then you can see which of the nodes are already in the
cache and do not need further post-processing.
Cheers,
Pjotr
--
Read this topic online here:
Hi Pjotr,
On 11 November 2014 10:48, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
That sounds good. You might even want to have a mapfilename, Readresult
somewhere in there, then you can see which of the nodes are already in the
cache and do not need further post-processing.
Perhaps
On 11 November 2014 10:50, Robert Osfield robert.osfi...@gmail.com wrote:
Perhaps placing a small cache object map into the osgDB::Options structure
would be appropriate, this way loaders can query either the locally
assembled one or the main one in the osgDB::Registry.
It all could get
HI All,
On 7 November 2014 17:30, Robert Osfield robert.osfi...@gmail.com wrote:
I have now written the basic code to move the management of the object
cache to with the DatabasePager when the it's used in conjunction with
object cache. I haven't yet tested it but have run out of week so
Hi Robert,
I ve been following this thread from the beginning since I had issues with
the database pager so I thought it might be related. I have different big
datasets so I am going to give it a shot tomorrow and ping you with the
findings
Nick
On Mon, Nov 10, 2014 at 5:12 PM, Robert Osfield
Because you also have to deal with subobject like proxy nodes and images that
you want to have in the cache option 2 and 3 will be pretty hard to implement.
Option one seems like the elegant solution as right now you can only activate
those post processing steps if you have a database pager (or
Hi Pjotr,
On 7 November 2014 09:07, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
Because you also have to deal with subobject like proxy nodes and images
that you want to have in the cache option 2 and 3 will be pretty hard to
implement.
Option one seems like the elegant solution as
Hi Pjotr,
I have been looking further into how to handle use of the object cache
alongside the DatabasePager and believe the best option will be for the
DatabasePager to disable use of object cache when it's loaded subgraphs and
handle the initial query against the object cache and final
robertosfield wrote:
I have been looking further into how to handle use of the object cache
alongside the DatabasePager and believe the best option will be for the
DatabasePager to disable use of object cache when it's loaded subgraphs and
handle the initial query against the object
On 7 November 2014 11:50, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
I don't know if it will be worth implementing a form of block in the
object cache to hold back attempts to read the same file whilst it's still
being loaded. If the second concurrent load attempt is being done by a
On 7 November 2014 11:23, Robert Osfield robert.osfi...@gmail.com wrote:
I have been looking further into how to handle use of the object cache
alongside the DatabasePager and believe the best option will be for the
DatabasePager to disable use of object cache when it's loaded subgraphs and
Hi Robert,
I tried your fix and it exposed a bug in my fix :)
The problem is that the readObjectFields method will add the object to the
_identifierMap. So all the other instances of that image in the same file will
be replaced by the created dummy object. In my fix this was an dummy image and
Hi Pjotr,
On 6 November 2014 09:44, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
I tried your fix and it exposed a bug in my fix :)
The problem is that the readObjectFields method will add the object to the
_identifierMap. So all the other instances of that image in the same file
will be
Hi Robert,
I'm still in the process of compiling, but I had a look at the code.
As I understand it an object is put in the registery cache by
Registry::instance()-readNode(), thats before FindCompileableGLObjectsVisitor
will traverse it. This means that you will get race conditions in
Hi Pjotr,
On 6 November 2014 12:52, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
I'm still in the process of compiling, but I had a look at the code.
As I understand it an object is put in the registery cache by
Registry::instance()-readNode(), thats before
FindCompileableGLObjectsVisitor
Hi Pjotr,
I still haven't decided upon a solution for the object cache related
threading issues, these are my thoughts:
1) Pass the post processing traversals like StateToCompile traversal on to
the Registry to call them directly after load and before the subgraph is
assigned to the cache. To
Hi Robert,
I saw that you put the new thread code on svn. I have experimented a little
with it and it seems to produce deadlocks on application shutdown for us. In
OperationThread::cancel you have replaced a while loop with a join. The problem
is that the previous code was periodically calling
Hi Pjotr,
Thanks for testing out the new code. I changed the code to use of join()
to address the false positives generated by valigrind when a thread is
stopped without the pthread_join() that it expects. Addressing this false
positive made it easier to determine the actual race condition,
I first got the deadlock on linux and only in release builds. On windows I was
able to reproduce it by placing a 1ms sleep line 403. Adding cancel helps but
then the thread will not do any clean up and valgrind spits out a 1mb log file
complaining about memory leaks. It's better to try to fix
Hi Pjotr,
Rather than go adding extra complexity elsewhere in the OSG to handle the
use of join() I have reinstated the original OperationThread::cancel()
implementation, but retained the join(), placing it after the old
while(isRunning()) {} loop. Having the join() there appeases valgrind and
Looks like the new code fixes the deadlocks.
Attached are my modifications to the InputStream to no modify images when they
come from a cache. Note that this is a quick fix.
Cheers,
Pjotr
--
Read this topic online here:
Hi Pjotr,
Thanks for the changes. I've implemented something similar, the main
difference is that I've added a _dummyReadObject member variable to
InputSteam and use this object to read the object fields that we wish to
ignore. Could you try svn/trunk version of include/osgDB/InputStream and
Hi Pjotr et. al,
On 27 October 2014 13:44, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
I'm with you on not changing an image (or other objects) state when it's
already in a cache. If people don't want this they should turn the cache
off or clear the cache or clone things in the cache or
Thanks for the helgrind tip. I think I pinpointed the crash in our program,
this is working from trunk:
As said we have multiple files that reference the same image for a texture, I
have found two spots that can cause problems:
- In InputStream::readImage(bool readFromExternal) at line 777 the
Hi Pjotr,
On 27 October 2014 10:58, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
As said we have multiple files that reference the same image for a
texture, I have found two spots that can cause problems:
- In InputStream::readImage(bool readFromExternal) at line 777 the program
could get
Hi Robert,
You said that you were working with shaders. A race condition that looks like
the Texture2D::setImage example above can also happen with shaders in .osg
files:
The method Shader_readLocalData can get shaders out of a cache when files are
referenced. Then later in Program::addShader
HI Pjotr,
On 27 October 2014 11:50, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
You said that you were working with shaders. A race condition that looks
like the Texture2D::setImage example above can also happen with shaders in
.osg files:
The method Shader_readLocalData can get shaders
robertosfield wrote:
In the case when the image is shared it looks to me like the best approach
would be to not allow any additional modifications to the image by the
InputStream::readImage() method. Even if you added mutex locks around the
write operations to the mutex you'd ended with
Hi Robert,
We too have some trouble with the database pager. It all started after we used
DatabasePager::setUpThreads to use more threads. We get memory corruption but
only on linux. Tried to use valgrind but then the problem does not occur.
We are still in the process of pinpointing it down,
Hi Pjotr,
On 24 October 2014 14:54, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
We too have some trouble with the database pager. It all started after we
used DatabasePager::setUpThreads to use more threads. We get memory
corruption but only on linux. Tried to use valgrind but then the
robertosfield wrote:
There are some specific .osgb threading issues related to initialization of
the wrappers. There is chance that you are hitting up against this. For my
own work I'm not currently testing against .osgb and get problems so I
believe the .osgb issues can be dealt with
Hi Pjotr,
On 24 October 2014 16:02, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
What about FindCompileableGLObjectsVisitor, it is run on the pager thread.
Is that visitor thread safe? Just had a quick look at it and there are too
many different paths in osg code I'm not familiar with to
On Fri, Oct 24, 2014 at 03:35:06PM +0100, Robert Osfield wrote:
Hi Pjotr,
On 24 October 2014 14:54, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
We too have some trouble with the database pager. It all started after we
used DatabasePager::setUpThreads to use more threads. We get
Hi David,
Could you post the whole modified files. What version of the OSG are you
working on?
FYI, I'm actually working on a osgTerrain related task right now,
developing a new TerrainTechnique that use shader based displacement
mapping. This new implementation is still underdevelopment so
Interesting chance. Are these nodes supposed to be called from the
DatabasePager for StateToCompile and main draw thread at the same
time? I would have thought it would only be reachable by one or the
other, but not both.
These are modified from svn trunk 14451, we were using 3.2.0 when it
was
Hi David,
On 23 October 2014 17:08, David Fries da...@fries.net wrote:
Interesting chance. Are these nodes supposed to be called from the
DatabasePager for StateToCompile and main draw thread at the same
time? I would have thought it would only be reachable by one or the
other, but not
We're getting a crash with some ive paged terrains, it was being ht
when the system was under load with 7 OSG application instances all
thrashing their pagers. I've tracked it down to a race condition and
included two patches, the first adds a sleep to greatly increase the
chance of the crash to
42 matches
Mail list logo
