glflush/glfinish

[haust]

When are those glflush/glfinish commands actually useful ??
At debug code ?? At actual game code ??

I've done some tests on my celeron 333/256Mb/TnT2 16Mo :
- whith glFinish : 86 FPS
- whith glFlush : 90 FPS
- whithout both : 96 FPS

What the heck ??!!

[DJ Tricky S]

As I understand it, glFlush() ensures that any buffered GL commands get processed, but glFlush() can return before the commands are completed (so that the video card can work in parrallel to the rest of your code). glFinish() on the other hand blocks until all previously issued commands are complete, thereby causing your main CPU to sit idle while you wait for glFinish() to return.

The idea is to have as much work going on simultaneously by both your main cpu and the graphics card. For example, your main game loop might look something like this:

while (1)
{
do_cpu_intensive_work();
swap_buffers(); // display back buffer from last frame - could call glFinish() in here to make sure that all drawing has completed (probably done implicitly though)
// render current geometry now
glBegin();
...
glEnd();
// now the graphics card works on processing the input commands; don't call glFinish() until after all CPU intensive work is done!

}

this way you can maximize the speed of your application by letting the cpu & graphics card work simultaneously.

I can't say for sure but I suspect that in your case you were calling glFlush() / glFinish() in a place where it would cause the cpu to idle while waiting on the graphics card.

Hope that helps!

Originally posted by haust:
When are those glflush/glfinish commands actually useful ??
At debug code ?? At actual game code ??

I've done some tests on my celeron 333/256Mb/TnT2 16Mo :
- whith glFinish : 86 FPS
- whith glFlush : 90 FPS
- whithout both : 96 FPS

What the heck ??!!

[foobar]

Because of the client server model of openGl (that is the client is the machine issuing GL commands -CPU- and the server is the machine executing them -Video Card- ) the two need a way of synchronising and glFlush/Finish is that mechanism.

It is not going to make a lot of difference on a Video-Card/CPU implementation other than the CPU may need to know when it is safe to draw to the Frame Buffer for drawing system text etc. Its main use is for network rendering where you want to know when it is time to start sending rendering commands over the network.

So unless you are doing network rendering or a very generic application you shouldn't be using them. In your measurements when yu use glFlush you are telling openGL 90 odd times per second to do something it is already doing and with glFinish not only are you telling it to do something it is already doing but you are waiting for it to finish and tell you so.

In DJ's example it is doing nothing for rendering speed because glFlush causes rendering to begin and unless you have the stupidest video card in the world it should have already started!!! If anything glFlush should be called before starting CPU intensive work. You might call glFinish before swapping the buffers if you were going to do some system drawing in the window ( Windows doesn't like this anyway and your video card may not like it much either).

Incedentally it may be better to interleave CPU intensive work and rendering commands by calling glClear (if you are using it) immediately after you swap the buffers so that the video card can interupt the rendering pipeline and clear the buffers while the CPU is busy. Ie. do the thing that the graphics card is slowest at while the CPU is working hard.

[nic]

I recently had a wierdness whereby I was drawing some textured quads from a display list. My main draw loop just called glCallList() and then I drew the buffer to the screen. It worked fine on my Mac but on the PC and on other Macs I got some wierd intermittent drawing. I finally found that if I threw a glFlush() after I called the list everything was groovin'

Later, Guy

[Kilam Malik]

Would it make sense to call the glFinish _before_ my gl calls? E.g.:


Draw()
{
glFinish();
realDraw();
}

main_loop()
{
Processing();
Draw();
}

So the glFinish() will appear at the latest possible point after processing.

Comments?

[Bob]

Think SwapBuffers() under Win32 automatically waits for the buffer to clear, before copying the doublebuffer to the framebuffer.

So callig glFinish would be like calling it twice, and then swap buffers.

In the Red Book, it says that using these functions in a non-network environment (network environent = where the OpenGL-calls are executed on one machine, and drawn on another) might have no effect.

[This message has been edited by Bob (edited 08-23-2000).]

[foobar]

The display list thing may also be due to the server client nature of openGL. Display lists are stored by the server, so when you use glCallList() very little data needs to be sent to the server. In a network environment sending a very small packet (containing just the display list id!) would be a bad idea so the call is not sent until you call glFlush() which would begin sending data over the network.

When you say you call glCallList() before drawing the buffer to the screen I assume you mean your display list is drawn immediately before you swap the buffers? Your PC video driver may take the approach that it 'hordes' display list calls and sends them in a bunch as if you called glCallLists(). This may then interfere with the buffer swapping. See if using glCallLists() has the same effect as using glFlush if you are interested but I can't see why the driver would take this approach - it is probably something more complex with the workings of your card.

[nic]

Originally posted by foobar:

When you say you call glCallList() before drawing the buffer to the screen I assume you mean your display list is drawn immediately before you swap the buffers?

Well, I don't want to bore you with details, but I am actually doing this within a 2d paint program. The updates are handled outside OGL. We therefore never call swapBuffer, that could be another reason why it would behave a bit differently for me...

Later, Guy

[haust]

Well people,

i guess i have some anwsers over here....
thanks !!

but keep talking about this : it's a pleasure to learn