[osg-users] Synchronizing with textures uploads.

[Robert Osfield]

Hi Altin,

On 8 March 2018 at 15:19, Altin Gjata <altingjataj at gmail.com> wrote:
> Just an update. Calling setDataVariance(osg::Object::DYNAMIC), either (or both) in quad's StateSet or in the texture itself doesn't seem to have any affect.
>
> In SingleThreaded mode it works OK.

Good to hear that this works.  This is important for understanding
what might be going amiss.

My best guess is that previously it was your view matrix that is one
frame behind rather than your texture update, as when you a call set
set the Camera's view matrix affects the current frame's traversal,
but in DrawThreadPerContext the current frame event, update and cull
traversals all can happen in parallel with the previous frames Draw
traversals, so if you update the view matrix it affects the current
frame, but if you also update the Image this is being read by the
previous frames draw traversal.  This will result in the video image
and view direction being out of sync.

SingleThreaded or CullDrawThreadPerContext both prevent the next frame
from starting before the draw dispatch is complete so will avoid this
issue.  I would also would have expected setting the DataVariance to
DYNAMIC on the StateSet that you attach your texture to would have
also prevented the next frame from starting before the texture was
dispatched, I can only guess that the something wasn't quite right
with the setting in your code.


> If the driver uses triple buffering, can I do anything to disable it?

I don't have any knowledge of Intel drivers under Windows so can't
help with this.

>
> I'm using OSG 3.5.6. I understand that it's neither the stable release nor the most updated development release, but it's the version that vcpkg installs.
> Maybe this is all irrelevant.
>
> The content of the entire source file is below, including the commented out hacks.

A quick can through it mostly looks OK, but it's kinda hard reading in
a browser, if possible in future could you post large segments of code
like this an attachment, this will make it easier to read with a the
readers preferred editor.

--

Personally, now you have it working with SingleThreded to stick with
this.  Unless you have really large models that have heavy cull and
draw traversals I would expect DrawThreadPerContext to make that much
difference.  If you do see performance issues with SIngleThreaded then
I'd recommend working on what the bottlenecks are rather than just
selecting the multi-threaded solution that in your case introduces
issues.

W.r.t performance issues, I would recommend starting a separate thread
to discuss these, thread as in mailing list/forum thread rather than
CPU one :-)

Robert.