AMD Catalyst 11.9 crashes with wglCreateContext

[Dan Bartlett]

If you have declared these functions yourself, rather than using Delphi's built in (out of date) OpenGL headers, then are you using the right calling convention for these functions? (eg. stdcall on Win32)

[BionicBytes]

Yes it's weired and yes I'm surprised noone else has mentioned it. There are some hit on Google however!
The code is Pascal Delphi and yes I have checked the function pointers over and over. Bare in mind that I have used the same code for nearly Ten years without incident (after all how often does wglCreateContext change)?

Anyway the issue resolved itself with your Cat 11.10 preview 2 drivers!
Something odd going on in your driver builds!

[Richard Müller]

I have exactly the same problem. After the update to Catalyst 11.9, the wglCreateContext function fails in one of my applications. The system reports a division by zero exception. I am also a Delphi programmer and I use the dglOpenGL interface unit of the DGL-OpenGl2-Portteam. Not all of my applications are affected. Unfortunately I cannot see why one application fails and the other doesn’t fail. It must have to do with the order of the function calls in the initialization routine (i.e. getting device context, setting pixelformat).

[BionicBytes]

If you have declared these functions yourself, rather than using Delphi's built in (out of date) OpenGL headers, then are you using the right calling convention for these functions? (eg. stdcall on Win32)

To answer your question: all OpenGL functions and extensions I have implemented my self (using stdcall) and I am not using any 3rd party OpenGL headers. All of these functions are known to work and have been for many years on both nVidia and AMD hardware. I only had a problem recently after switching driver version.....

[Richard Müller]

I want to point to another strange problem I was confronted with a while ago and I think it could give us an idea what the source of the problem might be. After a call to wglCreateContext, where I tried to get a rendering Context for a bitmap, the function returned with a changed (destroyed) CPU control word. It seemed as if the CPU was in an MMX mode and all subsequent floating point operations failed after this call to wglCreateContext. To solve the problem, I changed the code and I push the CPU control word before the call and restore it after the call to wglCreateContext. But this is a very unsatisfactory solution, because it is obvious that there is a problem with the implementation of the wglCreateContext function in combination with ATI gpus. The problem didn’t arise when I used wglCreateContext in order to get a rendering context for a window, only rendering contexts for bitmaps were affected.

Could it be that the catalyst 11.9 implementation of wglCreateContext forgets to switch back the CPU from the MMX state, i.e. forgets to empties the MMX state with the EMMS instruction?

[Dan Bartlett]

Ah, have you included the following code at initialization?

  Set8087CW($133F);

see http://docwiki.embarcadero.com/VCL/X...stem.Set8087CW

But why a floating point exception is happening on creating a context, I don't know.

I experienced a similar problem when calling a particular OpenCL function with AMD drivers. IIRC it was that it was dividing by zero + by default Delphi doesn't just ignore those errors, but Visual Studio does.

[Richard Müller]

Thank you for the hint.

As we use the dglOpenGl interface unit, the FPU control word is set during the initialization of the dglOpenGl unit:

initialization

{$IFDEF CPU386}
Set8087CW($133F);
{$ENDIF}

But when I check the control word before the first call to wglCreateContext, I find it changed again. Some other initialization routines seem to change the FPU control word, too. This could explain why not all of our applications are affected by the error. Dependent on when the initialization of the dglOpenGl unit takes place, the FPU control word is possibly but not necessarily changed afterwards by other routines.

I feel not happy with the solution to disable all floating point exceptions. As we develop commercial software for a branch where the safe operation of the software is required, I would prefer to get the exceptions when they occur. An exception is a clear indicator to the user that something went wrong. If the user cannot see the exceptions, he will not be able to recognize that something went wrong! That is not good programing style, isn’t it?

[BionicBytes]

Set8087CW($133F);

This is interesting and could explain why an exception is thrown for one set of drivers but not another.

I'll try and set the code in my engine and see what effect it has on the Cat 11.9 drivers which had the problem.

[Richard Müller]

The forum has obviously come to the result that all floating point exceptions of the cpu have to be disabled when OpenGl is used within an application. What do you think, is this true?

[Simon Arbon]

Although its not mentioned in any specification i can find, it seems to be quite common for OpenGL drivers to perform divisions by zero during their normal processing, so it is necisary to prevent this from raising an exception.
Every OpenGL.pas file i have back to Delphi 2 includes the Set8087CW($133f) command in its initialization.
There are posts on this forum going back to 2002 that recommend doing it.
My compiler documentation also mentions it:

It is recommended that you disable all floating-point exceptions when using OpenGL to render 3D graphics. To do this, call Set8087CW(0x133f) in your main form’s OnCreate event before calling any OpenGL functions.