Powerino73's picture

ATI Catalyst 10.7

Yesterday i installed in my system the ATI Catalyst driver 10.7, since that moment opentk doesn't work anymore..
Any suggestions other than install previous driver version?


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Any errors / exceptions that could help debug the problem?

c2woody's picture

I've noticed this as well, it seems to be a bug in the SelectGraphicsModeARB() function of OpenTK that does not lead to a crash in pre-10.7 drivers because the finally chosen pixel format is different.

Wgl.Arb.GetPixelFormatAttrib should be called with attribs.Length - 1 (number of requested attributes), and Wgl.Arb.ChoosePixelFormat as well as Wgl.Arb.GetPixelFormatAttrib return booleans to check for failures (missing in OpenTK currently). This is with the 10.6 drivers (same error as noted), didn't test yet whether it fixes the problem since I'm using old drivers for debugging/comparison at the moment.

the Fiddler's picture

Thanks for the heads up, let me upgrade my drivers to test.

c2woody's picture

If you haven't upgraded yet: check what Wgl.Arb.GetPixelFormatAttrib returns for you, so you can compare that to the 10.7 drivers. It returns false for both driver versions here (true if using Length-1).

zahirtezcan's picture

I have got the same problem, I have traced a bit too. Here is a problem I see:

When WinGraphicsMode calls SelectGraphicsModeARB, OpenGL returns attribs like this:
redbits: 16
greenbits: 16
bluebits:16
alphabits:16
but bitsperpixel: 48.
this used to return 8 bits per component. (This occurs for the requested 3.3 forward compatible context, intermediary version 1 contexts create well)
And this result is used to create a GraphicsMode whose bits per pixel is 64 with some index value (97 for my case)

Then context creation is issued and WinGLContext's SetGraphicsModePFD method is called. DescribePixelFormat does not fill the pfd structure (structure contents remain zero but RGBA) and SetPixelFormat fails.

c2woody's picture

DescribePixelFormat fails as well (when checking for this after the Wgl.Arb.GetPixelFormatAttrib call and returning null, the non-arb function will be used which works correctly).

c2woody's picture

Looks like the returned pixel format is broken/not what one would expect (it seems to match the requirements of the query though).

An interesting point is changing the code so

                    (int)WGL_ARB_pixel_format.DrawToWindowArb, 1,
                    (int)WGL_ARB_pixel_format.SupportOpenglArb, 1,

is present which makes the Wgl.Arb.ChoosePixelFormat to fail (the DrawToWindowArb being the relevant part). So the pixel format we got before was a PBuffer-related one (checking the pixel format in e.g. OpenGL Extensions Viewer).

Now when removing the alpha channel request (WGL_ARB_pixel_format.AlphaBitsArb and reducing ColorBitsArb to 24 bit instead of 32) we get a correct, working pixel format (actually the same that is selected by Functions.ChoosePixelFormat in SelectGraphicsModePFD). So none of the pixel formats for windowed output contains an alpha component (the extensions viewer verifies this, color bitsize is 24 for these pixel formats).

Any idea about this? Are alpha bitplanes obsolete for wglChoosePixelFormatARB or incompatible somehow?

c2woody's picture

ColorBitsArb should exclude the alpha bits. Requesting 32 (color bits is a minimum-requirement) will acquire a strange pixel format therefore, or none at all (which would be the correct thing to do) if draw to window is requested.
See http://msdn.microsoft.com/en-us/library/dd368826(VS.85).aspx for a description of the color bits entry.

Something like

                int alpha_bits = color.Alpha;
                int color_bits = color.BitsPerPixel;
                if (color_bits > alpha_bits) color_bits -= alpha_bits;

could be used, possibly having some additional constraints on alpha_bits (some sources say it can only be 0 or 8).

Also the attribs array has the RGBA sequence mixed up which is a problem for the later GraphicsMode construction.

the Fiddler's picture

Thanks, fixed the length, alpha bpp and attribs array issues. I've also improved error checking a bit and added support for single buffering.

Everything seems to work fine on my nvidia desktop, will test on ati asap.

c2woody's picture

Yes that looks good now.

Any implementation that uses wglChoosePixelFormatARB requests WGL_SUPPORT_OPENGL_ARB as well (only allow for pixel formats that are usable with OpenGL), so you might want to add WGL_ARB_pixel_format.SupportOpenglArb as well (haven't seen any non-OpenGL pixel format in current drivers' enumerations, but you never know how it looks on other systems/in the future).

About your comment on accum.BitsPerPixel: it's the sum of all RGBA bits (so including the alpha channel of the accumulator), at least when looking at the pixel format enumerations. So the current usage in OpenTK is correct and according to the specs.

Some strange thing noticed along with the WGL_SAMPLE_BUFFERS_ARB setting: as soon as it is found in the array (even if specified as OFF/GL_FALSE), only pixel formats that support multisampling are returned. This is pretty odd imo, maybe worth testing how different drivers behave for this, it does not seem to be a problem since (always?) some matching format is found, but maybe adding something for this (conditionally completely removing the WGL_ARB_multisample.SampleBuffersArb entry or so).