Stefan Eilemann wrote:
>
> Can it be that your draw time is limiting the fps? After all, you have
> four Channel::frameDraw per frame and node, which means that you'll
> need to draw faster than 4ms to reach 60Hz.
>
I'm drawing a spinning color cube as a test so the draw func is not
intensive. I'm doing some frame rate idling in the Application server run
loop ala the eqPly example:
while(pConfig->isRunning())
{
pConfig->startFrame();
pConfig->finishFrame();
pConfig->frameRateTiming();
}
frameRateTiming only eats up extra ms per frame to keep a constant FPS.
This works fine for FPS below 44. When I turn off the idling, I get the
same ceiling of 43-44 when running the wall. I am timing the fps in the
Node class and using the BitmapFont to display it so I can see the frame
rate of each node and they are pretty well consistent. Naturally, the same
application running locally get's a smooth 60 or 120 fps, so it must be in
how I'm doing the network timing.
Stefan Eilemann wrote:
>
> If you have vsync on, enable triple-buffering (if possible).
>
We are using GLX in Ubuntu and the nvidia driver only vsyncs one window in
multis creen mode, so no go for that. I'm not sure how to enable triple
buffering ... do I do that through equalizer or is it driver specific?
Stefan Eilemann wrote:
>
> The first step is to look into the statistics ('s' in eqPly) to see
> where the time is spent. I do often a screenshot, since it's easier to
> analyze then the constantly updating stats overlay.
>
> Ideally your four green draw operations should be nicely one after
> another, followed by a white swapbuffer. If that isn't the case, then
> we'll have to figure out where the time is spend. If it is the case,
> then you'll have to speed up your draw time.
>
>
I have been watching the stats and I do get the "stair step" pattern as
described, but with this test example, the draw time is so small that its
hard to see it.
I enclosed a screenshot of the stats when running without frame rate idling.
We are looking to try and get 60 fps for smooth animations, so I'm curious
to figure out where the bottleneck is.
--
View this message in context:
http://n2.nabble.com/60-Fps--tp1329911p1332258.html
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
_______________________________________________
eq-dev mailing list
[email protected]
https://in-zueri.ch/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
