Performance drop with bino #81

Closed
eile opened this Issue Jan 10, 2012 · 12 comments

Comments

Projects
None yet
3 participants
Owner

eile commented Jan 10, 2012

With Bino I see a performance problem that I did not see with Equalizer
1.0.1. On my home system (Ubuntu 11.10 amd64, NVIDIA 9600 with the
290.10 drivers) I only get up to 20 fps in Bino's benchmark mode. In
normal mode, that is too slow to keep up, so Bino drops all the frames.
With 1.0.1, I get > 150 fps in benchmark mode, and no frame drops occur
in normal mode.

eile was assigned Jan 10, 2012

Owner

eile commented Jan 10, 2012

Finally I get around to trying git bisect :)

I started with Equalizer current HEAD (bad) and release-1.0.1 (good).
Git bisect tells me that 9ab87c0
makes the difference (log attached). Before this, I get > 70 FPS with
my current test video, after it I get only ~20 FPS.

But I must admit that I don't understand the impact of this commit and
why it causes the drop in frame rate. I only see this happen with Bino,
not with my other application. So maybe Bino does something wrong here?

Owner

eile commented Jan 10, 2012

Hmmm, I tried to use current HEAD with
9ab87c0 reverted, but that did not
work - still ~20 FPS. Maybe I did something wrong when solving the
conflicts that 'git revert' caused. Or maybe the real cause is
something different...

Contributor

marlam commented Jan 30, 2012

Now I think I've got it. The problem was not 9ab87c0, but its parent, d4775a1. I must have misinterpreted the git bisect output. Anyway, after reverting d4775a1 (by putting #if 0/#endif around the body of the function Window::_initSwapSync() in libs/eq/client/glx/window.cpp), I again get full framerate (> 70 fps).

Now the question is what the problem with _initSwapSync() is.

Owner

eile commented Jan 30, 2012

glXSwapIntervalSGI( 1 ) sets the minimum interval between to swap buffers to be one vertical retrace. Unless I misunderstand something, this effectively syncs the swap to the next vertical retrace. If you set the swapsync hint to off, you should get 70Hz with a plain version.

The question is why you drop to 20FPS, or if there is another way to implement sync-to-retrace?

Contributor

marlam commented Jan 30, 2012

Yes, setting 'EQ_WINDOW_IATTR_HINT_SWAPSYNC OFF' fixes the problem.

Qt uses a combination of glXGetVideoSyncSGI and glXWaitVideoSyncSGI before calling glXSwapBuffers; see http://qt.gitorious.org/qt/qt/blobs/4.8/src/opengl/qgl_x11.cpp line 949ff. I'm not sure if that makes a difference.

Contributor

marlam commented Jan 31, 2012

I just tested replacing glXSwapIntervalSGI() with glXGetVideoSyncSGI()/glXWaitVideoSyncSGI() before glXSwapBuffers(), like Qt does, but I see the same frame rate drop to 20 fps (while eqPly runs smoothly at 60 FPS, like expected).

Since Bino seems to be the only affected application, there is probably something wrong with they way Bino uses Equalizer. I don't know what it is. For now, maybe I'll just recommend to set swapsync off when using Bino with Equalizer.

Owner

eile commented Jan 31, 2012

Can you attach a screenshot of the statistics overlay with and without swap sync? I would like to understand where the time is spent.

Owner

eile commented Jan 31, 2012

Btw, I will commit a change to bino making swapsync off by default for now.

Contributor

marlam commented Jan 31, 2012

On Mon, 30 Jan 2012 23:29:34 -0800, Stefan Eilemann wrote:

Can you attach a screenshot of the statistics overlay with and
without swap sync? I would like to understand where the time is spent.

Screenshots attached. Bino reports ~20 video frames per second with
swapsync, and > 200 without.

Martin

Owner

eile commented Jan 31, 2012

I can't see the files. I'm not even sure the issue tracker can do it. Can you send them per mail to me?

Owner

eile commented Jan 31, 2012

After discussion this has been identified as a bino issue. Bino renders at 60Hz but reads the video frames at 20Hz.

Closing issue.

eile closed this Jan 31, 2012

63n commented Jul 30, 2014

Could someone pls describe this 20Hz issue, or provide a link?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment