wglChoosePixelFormatARB for MSAA very slow

Florian Rammerstorfer · 2014-03-26T19:44:26

I am using the tutorial from NeHe Productions http://nehe.gamedev.net/tutorial/fullscreen_antialiasing/16008/ on how to enable MSAA on a gl context. It all works fine, but the funciton call to wglChoosePixelFormatARB() is very, very slow. Usually takes about 2-3 second(my pc is a gaming pc, so it should run muchf faster). Does anyone know why this function is so slow and is there a workaround/solution?

Graphics and GPU Programming Programming

Started by Florian22222 March 23, 2014 04:28 PM

12 comments, last by Florian22222 10 years ago

samoth

9,833

March 24, 2014 02:25 PM

3.4ms in release build

That is a figure that I would expect, to be honest! "Few milliseconds at most" is the answer I'd shout out if I didn't know otherwise. It certainly can't take much longer, actually (yet... it does).

Though not as horrible as stated by the OP's case, my machine (incidentially very similar, GTX650Ti / 332.21, but used to be the same on GT9800 with 177.x drivers) takes clearly noticeable time just to bring up the window.

I haven't benchmarked it to the millisecond since there's not much to do about it anyway (it takes what it takes!), but I'd guess it's something between half a second and one second here, just to initialize the context and pop up the window.

mark ds

1,787

March 24, 2014 03:45 PM

Though not as horrible as stated by the OP's case, my machine (incidentially very similar, GTX650Ti / 332.21, but used to be the same on GT9800 with 177.x drivers) takes clearly noticeable time just to bring up the window.

For completeness, for me to create a dummy window, initialise glew, destroy the window, create a new window, do the usual GL setup, show the window and call swapbuffers takes ~400ms from a reboot. That includes some fairy small allocations, too. It takes about 300ms on the second launch. I launched the exe from Explorer, not the IDE.

IceBreaker, if you want to post code, I'm happy to try it. Either something else is going on, or maybe you're timing is in error?

21st Century Moose

13,459

March 24, 2014 06:04 PM

Try taking this:


		WGL_DEPTH_BITS_ARB,16,
		WGL_STENCIL_BITS_ARB,0,

And switching to:


		WGL_DEPTH_BITS_ARB,24,
		WGL_STENCIL_BITS_ARB,8,

Or:


		WGL_DEPTH_BITS_ARB,32,
		WGL_STENCIL_BITS_ARB,0,

The reason why is that this switch will greatly narrow down the number of pixel formats that are going to pass selection. Again, looking at the spec we see the following note:

Some attribute values must match the pixel format value exactly when the attribute is specified while others specify a minimum criteria, meaning that the pixel format value must meet or exceed the specified value.

And in the table following this we see that depth bits and stencil bits are two that must meet or exceed the specified values. So in other words, these operate as a "greater than or equal to" option; so by specifying D16 we're also going to get all of the D24 formats, the D24S8 formats, the D32 formats, etc.

All reasonably modern hardware (i.e in the order of no more than 8 years old) will support a 24-bit depth buffer with 8-bits stencil, so this is an absolutely safe option to choose.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

mark ds

1,787

March 25, 2014 01:45 AM

Just an idea... Did you create a dummy window to get the function pointers, and then destroy it? And then use a new window to get the pixel formats?

Fiddler

859

March 26, 2014 09:37 AM

I have encountered this issue several times over the past 8 years while working on OpenTK. It only appears to affect Nvidia cards, and I haven't managed to locate the exact causes. Changing driver versions tends to make this go away.

Suggestions:

Use apitrace to capture a log of WGL / GL calls on the slow system, and compare that to a fast system. Upload the log somewhere and post a link here - we might be able to uncover something.
Call LoadLibrary("opengl32.dll") before invoking any WGL or GDI functions (including creating a window or querying pixel formats). This appears to help.
For functions that have both GDI and WGL prototypes, use the GDI one. This requires point 2 above, otherwise you program may crash due to weird historical reasons.
Edit: when you create a temporary context to load WGL extensions, keep the temp context alive for the wglChoosePixelFormatARB call. This may or may not have an effect here, but it will certainly fix random crashes on specific Intel drivers.
Try flipping the "Threaded Optimizations" option in the Nvidia control panel. Yes, sometimes this does make a difference...
If everything else fails, contact Nvidia with a test case that reproduces the issue.

I would really love to get to the bottom of this, but reports are so sporadic that it's really hard to pin down the causes.

[OpenTK: C# OpenGL 4.4, OpenGL ES 3.0 and OpenAL 1.1. Now with Linux/KMS support!]

Florian22222

618

Author

March 26, 2014 07:44 PM

It kinda seems to have fixed itself. It's now much faster although I didn't change anything on my system...Still takes its time, but not that bad anymore.

I tried adding LoadLibrary() but that didnt change much.

Thanks for your help anyway I think I can live with this half a second at startup.

wglChoosePixelFormatARB for MSAA very slow

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

wglChoosePixelFormatARB for MSAA very slow

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines