[osg-users] How to ensure stable execution of the GPU?
robert.osfield at gmail.com
Sat Jul 19 01:56:05 PDT 2008
As I mentioned in the previous thread, the position of the GPU stats
is just an estimate, because the GPU stats extension only times
duration between two timing token, not the absolute time that either
were actually made. I therefore have to estimate the position given
the only fixed times that we know about i..e when the timing tokens
were received and when they were first dispatched. So please don't
read too much into their absolute position, the glitch you are seeing
is most likely just a symptom of something else wrong.
Now glitches in the frame rate is a problem that you will need to
address, there could be a range of reasons for it, it could be related
to the rendering down on the GPU, or it could be a CPU bound issue on
your app, or something unrelated - i.e. what the OS and other
processes that are running on your machine.
Which of these might it be... we'll it's impossible for me to say, one
just has to test each possibility out in turn. Start from the most
likely candidates first, or perhaps just the easiest ones to discount.
The first thing I'd do is make sure as few other processes are
running on the machine as possible, i.e. stuff like search tools that
run periodically, or security tools etc. Next up I'd look to process
shifting from one core to another.
On Fri, Jul 18, 2008 at 10:50 PM, Alf Inge Iversen <alf-inge at autosim.no> wrote:
> We have a problem with significant stepping in our visualiation application, and have traced the problem down to how execution of the GPU is trigged.
> First some general information:
> We are currently using OSG 2.2 (the application is upgraded to OSG 2.4 few weeks ago, but this new version will not be released to customers until late fall due to sync'ing with the release of other software modules. So we are stuck with 2.2 for now). The systems run on the Windows XP platform, using Nvidia boards in the range 7600GS to 8800GTS. The viewer application is based on the osgViewer::Viewer class, displaying two channels (a main channel with an embedded mirror channel). The test described below is run on a dual-core 3.4 GHz processors and 7900GS graphics boards.
> By visually observing the OSG stats, together with printouts to the console window to detect lost real-tme position data, we have observed that even if no datasets are missing and the computing time is well inside the available time slot, glitches occur. When observing the stats, we realized that the execution of the GPU happen to be performed sometimes within the current frame (see attached image GPU-early.jpg), sometimes in the next frame (see GPU-late.jpg). The shift from one frame to the next or vice versa can happen several times a second, or it can happen only now and then. For every shift, a significant glitch in the visualization can be observed.
> Q1. What causes the GPU to wait for execution some frames, and in other frames execute immediately when new data is available?
> Q2. Is it possible to force the GPU to wait to process the available data until a given signal (for example vertical sync)? If so, how?
> Some latency can be accepted if the image is stable. So to ensure a stable image, it should be possible to lock the start of the GPU processing to the vertical sync. It would then process on data delivered last frame from the Draw dispatcher. This would give a stable image, in addition to increase the available time for the processing (full 16 ms for Update, Cull and Draw, and another full 16 ms for the GPU).
> It has been mentioned that multithreading could help out. But as the attached pictures show, there is no relationship between load and when the GPU processes. Hence, improved efficency by introducing multithreading would still not ensure stable GPU processing. Very brief tests with our newer version shows the same tendency with glitches in multithread mode.
> We appreciate any suggestion that help us solve our problem.
> -Alf Inge
> Mr. Alf Inge Iversen, VP Engineering
> AutoSim AS, Strandveien 106, 9006 Tromsø, Norway
> Visit us at http://www.autosim.no
> osg-users mailing list
> osg-users at lists.openscenegraph.org
More information about the osg-users