Discussion:
[osg-users] Latency
David Heitbrink
2018-10-01 17:25:19 UTC
Permalink
I currently have an odd problem I am stuck on. I have a system with 2 Quadro P5000 cards- driving 3 displays that are warped and blended on a 120 degree dome. Running Windows 10. The application is ground vehicle simulation - I have pretty high rates of optical flow. Each display is running its own process, they receive a UDP broadcast with position update information. What I am seeing is 1 of the displays is off by 1 frame 95% of the time. When this happens....my blending fails and I get a large seam in my scene. I added logging as to the eye point position as well as high frequency counter time.

From what I can tell from the logs, the return from the VSync's (viewer->frame() ) are all within 200 microseconds, and the eye point position and data frame number (i.e. the frame number for my incoming data) is the same across all of the channels.

So I strongly suspect this has something to do with the graphics card/driver's own internal frame buffering....and there is not a lot I can do about it.

This leaves me with a couple of real issues.....
1) Programmatically cannot tell if a channel is a frame behind or not. Basically I added buffering for the other 2 channels for position information......and my seam goes away 95% of the time
2) Since things are not 100% the same.......I randomly get a seam 5% of the time (assuming I am buffering).

At this point I don't know what to do.....I have talked to NVidia about this, they mentioned making sure DPI scaling in windows is set to 100% and/or setting up the app to be DPI aware. I have done this.....but I get the same result.


Any advice and/or speculative guesses on this would be great.

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75001#75001
Voerman, L.
2018-10-02 07:26:40 UTC
Permalink
Hi David,
are your cards running in "quadro mosaic" mode or are they configured as
independent cards? Our win7 machine is driving 6 channels from 2 cards for
a cylindrical theatre, and have no problem running in full sync (stereo as
well as monoscopic view).
Laurens.
Post by David Heitbrink
I currently have an odd problem I am stuck on. I have a system with 2
Quadro P5000 cards- driving 3 displays that are warped and blended on a 120
degree dome. Running Windows 10. The application is ground vehicle
simulation - I have pretty high rates of optical flow. Each display is
running its own process, they receive a UDP broadcast with position update
information. What I am seeing is 1 of the displays is off by 1 frame 95% of
the time. When this happens....my blending fails and I get a large seam in
my scene. I added logging as to the eye point position as well as high
frequency counter time.
From what I can tell from the logs, the return from the VSync's
(viewer->frame() ) are all within 200 microseconds, and the eye point
position and data frame number (i.e. the frame number for my incoming data)
is the same across all of the channels.
So I strongly suspect this has something to do with the graphics
card/driver's own internal frame buffering....and there is not a lot I can
do about it.
This leaves me with a couple of real issues.....
1) Programmatically cannot tell if a channel is a frame behind or not.
Basically I added buffering for the other 2 channels for position
information......and my seam goes away 95% of the time
2) Since things are not 100% the same.......I randomly get a seam 5% of
the time (assuming I am buffering).
At this point I don't know what to do.....I have talked to NVidia about
this, they mentioned making sure DPI scaling in windows is set to 100%
and/or setting up the app to be DPI aware. I have done this.....but I get
the same result.
Any advice and/or speculative guesses on this would be great.
------------------
http://forum.openscenegraph.org/viewtopic.php?p=75001#75001
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Robert Osfield
2018-10-02 07:30:08 UTC
Permalink
Hi David,

It's not possible to know specifically what is wrong without having
your hardware, software and data available to test, even with these
one might well need inisght from NVidia to unravel what is going on.

From your description it sounds like you are running three separate
slave applications and a master that controls them. If so have you
tried just a single application and using the osgViewer with a single
Viewer and three slave Camera with a GraphicsWindow on each?

Within your application are you application are you setting up and
swap ready and swap buffer mechanism?

If you can try running your application on another OS, especially one
that you can switch off go closer to the metal and switch off
compositing.

Robert.
Post by David Heitbrink
I currently have an odd problem I am stuck on. I have a system with 2 Quadro P5000 cards- driving 3 displays that are warped and blended on a 120 degree dome. Running Windows 10. The application is ground vehicle simulation - I have pretty high rates of optical flow. Each display is running its own process, they receive a UDP broadcast with position update information. What I am seeing is 1 of the displays is off by 1 frame 95% of the time. When this happens....my blending fails and I get a large seam in my scene. I added logging as to the eye point position as well as high frequency counter time.
From what I can tell from the logs, the return from the VSync's (viewer->frame() ) are all within 200 microseconds, and the eye point position and data frame number (i.e. the frame number for my incoming data) is the same across all of the channels.
So I strongly suspect this has something to do with the graphics card/driver's own internal frame buffering....and there is not a lot I can do about it.
This leaves me with a couple of real issues.....
1) Programmatically cannot tell if a channel is a frame behind or not. Basically I added buffering for the other 2 channels for position information......and my seam goes away 95% of the time
2) Since things are not 100% the same.......I randomly get a seam 5% of the time (assuming I am buffering).
At this point I don't know what to do.....I have talked to NVidia about this, they mentioned making sure DPI scaling in windows is set to 100% and/or setting up the app to be DPI aware. I have done this.....but I get the same result.
Any advice and/or speculative guesses on this would be great.
------------------
http://forum.openscenegraph.org/viewtopic.php?p=75001#75001
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
David Heitbrink
2018-10-04 20:10:45 UTC
Permalink
I am not running it in Quadro mosaic mode. I do have a slightly older version of the program running on a render cluster with 5 2-gpu nodes driving 16 displays that runs fine on windows 7.

I am starting to suspect it has something to do with the Windows - Desktop Window Manager (DWM) composition. This can no longer be disabled in windows 10.

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75037#75037
Voerman, L.
2018-10-08 07:23:12 UTC
Permalink
I suspect the cards are not running in sync, to get useful info out of the
timing of viewer->frame() (in singlethreaded mode) you will have to add a
glFinish() call. Only if you force the driver to block until the
swapbuffers is actually done the timing info has meaning.
Laurens.
Post by David Heitbrink
I am not running it in Quadro mosaic mode. I do have a slightly older
version of the program running on a render cluster with 5 2-gpu nodes
driving 16 displays that runs fine on windows 7.
I am starting to suspect it has something to do with the Windows - Desktop
Window Manager (DWM) composition. This can no longer be disabled in windows
10.
------------------
http://forum.openscenegraph.org/viewtopic.php?p=75037#75037
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Continue reading on narkive:
Loading...