Why is glViewport slow?

OpenGL OpenGL: Advanced Coding
1

For reasons I’m not very proud of, I called glViewport three times per frame. That was obviously not necessary, but what surprised me was that my profiler indicated glViewport consumed 5% of the elapsed time. Why is glViewport that expensive? It seems a bit out of proportion for just setting the device-to-window transformation…

Thanks,

/Jonas

PS. I use a GeForce3 with Nvidia’s 30.82 drivers.

2

Just a guess: It probably has to go asking GDI about other child windows in the main window, and possibly even sycnrhonize up with a GDI flush.

shudder

3

Jonas,

That doesn’t make any sense to me either. Do you have a simple example I could pass along to the driver folks to take a look at?

Thanks -
Cass

4

Maybe You should use glScissor instead of glViewport?

5

Cass,

Talking about the drivers guys. Passing in NULL as ‘attributes’ parameter to wglCreatePbuffer (which is fine according to the spec) still gives an access violation in NVOGLNT.dll in the 40.72 drivers.
I’ve already reported this here http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/007527.html
but apparently nobody of you guys read it

Cheers.

6

Maybe glViewport is making up 5% of the calls (more or less).

V-man

7

Originally posted by Asgard:
[b]Cass,

Talking about the drivers guys. Passing in NULL as ‘attributes’ parameter to wglCreatePbuffer (which is fine according to the spec) still gives an access violation in NVOGLNT.dll in the 40.72 drivers.
I’ve already reported this here http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/007527.html
but apparently nobody of you guys read it

Cheers.[/b]

Asgard,

Sorry I didn’t notice your earlier post.

Looking at the extension spec in the registry, I’m not sure how you came to the conclusion that passing in a NULL pointer for the <piAttribList> argument of wglCreatePbufferARB is valid.

&lt;piAttribList&gt; is a list of attributes {type, value} pairs
containing integer attribute values.  All of the attributes in the
&lt;piAttribList&gt; are followed by the corresponding required value.
The list is terminated with a value of 0.

My reading of this is that you keep reading the contents of <piAttribList> until you find a zero. That’s exactly what the driver does.

It’s utterly trivial to “fix” this behavior by checking for NULL, but that doesn’t seem to be what the spec says. Is there something I’m missing?

[This message has been edited by pbrown (edited 10-07-2002).]

8

From WGL_ARB_render_texture:

Modify wglCreatePbufferARB: 

        HPBUFFERARB wglCreatePbufferARB (HDC hDC, int iPixelFormat, 
            int iWidth, int iHeight, const int *piAttribList); 

<snip>

        <piAttribList> may be NULL or empty in which case all attributes assume
        their default values as described below.
9

Dueling specs. How nice. :slight_smile:

I will update our driver tomorrow to implement the behavior specified in ARB_render_texture, since it’s obviously the less restrictive behavior.

To be on the safe side for “old” drivers, I’d recommend passing in a list of zeroes instead of using a NULL pointer.

Thanks for the heads-up.

10

You’re right, V-man. 5% doesn’t say very much.

In my test-run, glViewport takes two times longer to execute than a standard 4x4 matrix transpose. That’s maybe not too bad, after all.

/Jonas