Re: [osg-submissions] Multi-threaded usage of textures

2017-10-26 Thread Anish Thomas
Hi Ulrich, The updating of a texture's images happen before the image's modified-count is updated by the dirtying thread. This means that even if a third thread updates the image in the mean-time, this new update doesn't get missed from being uploaded to VRAM as the texture-upload happens

Re: [osg-submissions] Multi-threaded usage of textures

2017-10-26 Thread Ulrich Hertlein
Hi Anish, Looking at the fix I don't think this works in all cases, it only makes it less likely to occur. The check and the set are still done non-atomically, so another thread could be scheduled inbetween and one update would be lost. My preferred solution would be to use std::atomic with

Re: [osg-submissions] Multi-threaded usage of textures

2017-10-19 Thread Robert Osfield
H Anish, Thanks for the fixes, I've merged them with the OpenSceneGraph-3.2 branch and then applied similar changes to OpenSceneGraph-3.4 branch and master, I couldn't apply the changes directly to these as the code base has changed a little too much to make a direct merge easy. Could you test

Re: [osg-submissions] Multi-threaded usage of textures

2017-10-17 Thread Eric Sokolowsky
This could apply to a problem I have been having in my own application. Please post your fix once you have it. On Oct 17, 2017 5:01 AM, "Anish Thomas" wrote: > Hi Robert, > > I can submit a fix then. > Thanks for the quick reply. > > Cheers, > Anish > > > robertosfield

Re: [osg-submissions] Multi-threaded usage of textures

2017-10-17 Thread Anish Thomas
Hi Robert, I can submit a fix then. Thanks for the quick reply. Cheers, Anish robertosfield wrote: > Hi Anish, > > > > I think you are correct, the way to handle concurrrent reading/updates of an > osg::Image is to take a local copy of the osg::Image::getModifedCount() prior > to reading

Re: [osg-submissions] Multi-threaded usage of textures

2017-10-17 Thread Robert Osfield
Hi Anish, I think you are correct, the way to handle concurrrent reading/updates of an osg::Image is to take a local copy of the osg::Image::getModifedCount() prior to reading from the image and then use this value. This would still have the danger of the image data being updated at the same