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
osg-users@lists.opens
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 maili
Hi All,
On 11 November 2014 11:17, Robert Osfield wrote:
> My current inclination is create a new class osgDB::ObjectCache and have
> this manage a local std::map, have osgDB::Registry "have
> a" ObjectCache, and also let osgDB::Options have a local ObjectCache
> ref_ptr<> to manage a local user
On 11 November 2014 10:50, Robert Osfield 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 quite sticky if we are
Hi Pjotr,
On 11 November 2014 10:48, Pjotr Svetachov wrote:
> That sounds good. You might even want to have a map
> somewhere in there, then you can see which of the nodes are already in the
> cache and do not need further post-processing.
>
Perhaps placing a small cache object map into the osg
That sounds good. You might even want to have a map
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:
http://forum.openscenegraph.org/viewtopic.php?p=61571#61571
Hi Pjotr,
On 11 November 2014 10:30, Robert Osfield wrote:
> On 11 November 2014 09:54, Pjotr Svetachov
> 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 t
Hi Pjotr,
On 11 November 2014 09:54, Pjotr Svetachov 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
> most common use case
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 th
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
w
HI All,
On 7 November 2014 17:30, Robert Osfield 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 will
> need to return to
On 7 November 2014 11:23, Robert Osfield 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 que
On 7 November 2014 11:50, Pjotr Svetachov 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
> DatabasePager thread t
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
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 insertion
Hi Pjotr,
On 7 November 2014 09:07, Pjotr Svetachov 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 right now you can only
>
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,
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 do
Hi Pjotr,
On 6 November 2014 12:52, Pjotr Svetachov 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 will traverse it. T
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
FindComp
Hi Pjotr,
On 6 November 2014 09:44, Pjotr Svetachov 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 replaced by the creat
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,
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
Inp
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:
http://forum.openscenegraph.org/viewtopic.php?p=61524#61524
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
so
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 th
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, but.
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 et. al,
On 27 October 2014 13:44, Pjotr Svetachov 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 whatever they need.
> O
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
HI Pjotr,
On 27 October 2014 11:50, Pjotr Svetachov 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 out of a cache when f
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 t
Hi Pjotr,
On 27 October 2014 10:58, Pjotr Svetachov 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 an image from the ca
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 p
On Fri, Oct 24, 2014 at 03:35:06PM +0100, Robert Osfield wrote:
> Hi Pjotr,
>
> On 24 October 2014 14:54, Pjotr Svetachov 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
Hi Pjotr,
On 24 October 2014 16:02, Pjotr Svetachov 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 make an
> assessment fo
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 w
Hi Pjotr,
On 24 October 2014 14:54, Pjotr Svetachov 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 problem
> does not occur
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, s
Hi David,
On 23 October 2014 17:08, David Fries 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 both.
>
In the
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 f
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 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 r
43 matches
Mail list logo
