OpenGL drivers on Matrox P650

[Wiggers]

I have written an OpenGL program for a project at work. When I run it on my development computer it gives the correct vendor and version information. http://www.markwigmore.co.uk/images/...s3D_MR7000.jpg When I run it on my home computer with the P650 card it is very slow and gives the vendor as Microsoft. http://www.markwigmore.co.uk/images/...cks3D_P650.jpg The strange thing is that X-Plane gives the correct information on the P650 machine. http://www.markwigmore.co.uk/images/opengl/xplane.png

Why does my application not find the correct drivers?

[dorbie]

You probably have a software context that's falling back on the software emulation path. I assume it runs really slowly as well :-). Try changing your pixel format descriptor or perhaps ennumerating them and picking one you want.

[Wiggers]

We're using a bought-in framework to encapsulate a lot of OpenGL stuff. I've found the following, which might be of interest:

PIXELFORMATDESCRIPTOR DefaultPixelFormat =
{
sizeof(PIXELFORMATDESCRIPTOR), // size of this pfd
1, // version number
PFD_DRAW_TO_WINDOW | // support window
PFD_SUPPORT_OPENGL | // support OpenGL
PFD_DOUBLEBUFFER, // double buffered
PFD_TYPE_RGBA, // RGBA type
24, // 24-bit color depth
0, 0, 0, 0, 0, 0, // color bits ignored
0, // no alpha buffer
0, // shift bit ignored
32, // accum buffer bitplanes
8, 8, 8, 8, // accum bits
16, // 16 bit z-buffer
0, // no stencil buffer
0, // no auxiliary buffer
PFD_MAIN_PLANE, // main layer
0, // reserved
0, 0, 0 // layer masks ignored
};

The provider also gave a code snippet to change the Z-buffer to 32 bit, which I'm using.

[Jan]

Instead of 24 Bit color, use 32 Bit and therefore also set the alphabits to 8. There are some cards which don´t support 24 Bit buffers. (And you DO request an RGBA buffer!)

Set your z-buffer to 24 Bit and your stencil buffer to 8 Bit. You might not need the stencil buffer, however most cards are optimized for the use of 32 Bit depth-and-stencil buffers.

If you don´t need it, don´t request an accumulation-buffer. I think one of ATIs more recent cards was the first, which supported it in hardware, so that will be a big issue with all other cards. If you really need the accumulation-buffer, it is quite certain, that you won´t ever get hw acceleration on a lot of cards.

Hope that helps,
Jan.

[Wiggers]

Thanks for your comments, very useful. I have just been browsing the MSDN help file for PIXELFORMATDESCRIPTOR and it says, "cColorBits - Specifies the number of color bitplanes in each color buffer. For RGBA pixel types, it is the size of the color buffer, excluding the alpha bitplanes. For color-index pixels, it is the size of the color-index buffer." So, from that, it looks like the value of 24bits is correct. What do you think?

[Wiggers]

BTW, I've just set the 'accum buffer bitplanes' to 0 and I now get the right drivers being loaded. The only problem is there's no colour on the 'pipes', but the blue planet is still there. This is very strange because I have tested this program on the P650 machine before and it seemed to work perfectly. Must be something I've added recently that has flipped it.

[Wiggers]

Have just been searching the various forums for 'Matrox' and found a lot of negative stuff. Sorry not to have done that sooner.

I have managed to get the colour back into the 'pipes' by changing glColorMaterial to glMaterial inside the DLs. The distant lines are still black and I have noticed that memory is continually being allocated while the display is running, which takes nearly 5mins to free after the program exits! Doesn't happen on my ATI dev PC. Maybe I'll just get a 'proper' graphics card instead... ;-)

Was looking at FX5700U based cards. Are there any brands to be avoided as far as OpenGL drivers are concerned?