glClear too slow?

OpenGL OpenGL: Basic Coding
#1

Hi, this should probably go in the advanced forum, but it doesn’t seem to work, so I’ll post it here.

Calling a glClear (GL_COLOR_DUFFER_BIT | GL_DEPTH_BUFFER_BIT) is a pretty easy function that should take no time to execute. Most of the time it’s true, I experience no problem with the function which execute in aroud 0.03ms.

But here and there a have a spike in that function. The spikes last approx. 7ms. Any idea why that would be slow?

P.S. OS is win2000, computer is a SimFusion (home made card base on Radeon 9700 chips.

#2

Originally posted by vince:
Calling a glClear (GL_COLOR_DUFFER_BIT | GL_DEPTH_BUFFER_BIT) is a pretty easy function that should take no time to execute.

Clearing buffers is one of the most expensive operations you can make. You should keep it to a minimum. Use scissoring if you want to try to ‘save’ on clearing parts of the buffer. Personally I would look elsewhere for performance gains.

[This message has been edited by roffe (edited 03-13-2004).]

#3

One thing you can try to do is that if every frame your rendering over every pixel (for example, if you hgave a skybox), then just clear the depth buffer and not the color buffer. This is because you dont need to clear the color buffer since every pixel will be re-rendered anyway.

#4

Most of the time it’s true, I experience no problem with the function which execute in aroud 0.03ms.

But here and there a have a spike in that function. The spikes last approx. 7ms. Any idea why that would be slow?

Might it be caused by vsync, or a background task running ?

#5

That’s weird. I moved my clear screen somewhere else in the code and I don’t see the problem with the glClear any more. But it’s is somewhere in a different gl function. I don’t have any glError and my process is realtime with time critical priority. Don’t see what can have a higher priority than that.

#6

If you have a very simple scene then it’s possible the driver is queueing up a whole load of data and only evicting it once the queue is full. As it’s batching you’ll see functions returning almost immediately, once the queue is full then a whole load of work needs to be done and you see what should be a simple function take way longer than expected.

If you have an interactive application then you should be able to notice this as input will feel laggy as the driver batches.

One test of this theory would be to read a single pixel from the frame buffer after each frame. You should see overall worse, but more level performance as the driver has to flush the queue constantly to ensure the correct value is returned.

[edited for clarity]

[This message has been edited by SmutMonkey (edited 03-14-2004).]

#7

Or you could just throw in a glFlush and a glFinish and look if anything changes.

Jan.