Slow in last glVertex2f()

OpenGL OpenGL: Advanced Coding
1

I know it cannot be true that a single call of glVertex2f() takes 2 seconds to finish on my computer with Quadro FX 550/PCI/SSE2.

But it did!

The problem happens randomly. But when it happens, it’ll keep happening. It happens with both debug and release builds.

We have a render loop which keeps binding and draw textures. I’ve narrowed down to a block of codes as below:

/*
glBegin( GL_QUADS );
glColor4f( 1.0, 1.0, 1.0, alpha );
glNormal3f( 0, 0, 1 );

		glTexCoord2f( 0.0f, 0.0f );
		glVertex2f( -1, -1 );

		glTexCoord2f( 0.0f, 1.0f );
		glVertex2f( -1, 1 );

		glTexCoord2f( 1.0f, 1.0f );
		glVertex2f( 1, 1 );

		glTexCoord2f( 1.0f, 0.0f );
		glVertex2f( 1, -1 );	//very slow here!
	glEnd();

*/

The last glVerex2f() takes more than 2 seconds to finish. Any idea what could be the reason? Some bottleneck scenario happened?

P.S. Though it’s slow saving when the problem happens, all the frames rendered/saved are correct.

2

Does the problem really happen at random? Could it be related to the recently ack’d 48MB problem? Are you 100% sure it’s the vertex call and not the end call?

Anyway, I’d suggest to at least use arrays; if possible VBO’s.

(one thing I just remembered biting me once: If you’re on Win32, you’re not using two or more threads, where the render thread has different priority than the window (HWND) managing thread?)

3

tamlin, what’s the 48MB problem?

4

I’m also interested to know that 48MB problem. What was it?

5
6

Regarding he 48MB problem, I searched the board but couldn’t find it. Perhaps it wasn’t 48MB? As I remember it, it was a problem with some kind of buffers that created “hickups” and (IIRC) some nvidia guy acknowleged the problem and wrote it’d be fixed in the next version. If anyone remembers the thread, please pitch in.

muvee: The multithreading problem that bit me was that ATI’s user-mode driver part assumed the window managing thread was running at the same priority as the rendering thread, and in an attempt to reduce latency when waiting for the rendering to complete (as there is no hardware interrupt to signal this) they looped basically
while (card_not_finished_work) { Sleep(0); }

Well, as Sleep(0) only releases the time slice for threads of the same (or higher) priority, the rendering thread never got to write this memory while the main thread busy-waited like crazy, and it took (IIRC) around 2 seconds for this to sort out (whether it was due to thread priority inversions or something else I don’t know).

7

In the latest divers releases 48MB hickup seems fixed. Im not from nvidia but mmy app doesnt report such problem.