OpenGL on newer ATI graphics cards

Hello,

we could not get any OpenGL application compiled with ftn95 (tested with versions from 5.21 up to the current release) to run with a recent ATI card (Radeon HD 5770) on windows7 64bit. This has been verified on different systems (including win7 64bit enterprise, as well as win7 64bit RC). Graphics card drivers from Catalyst 9.12 to the current 10.2 have been tested, driver settings do not have an effect on the problem.

The problem manifests in a hard crash of the application (message 'application does not work any longer' without further useful information) which happens even with a plain fortran application that has only a %og and no additional processing related to GUI/OpenGL.

Using an external debugger the problem has been traced down to the ATI OpenGL driver component where a floating point exception happens. This is a result of ftn95 changing the default fpu control word when parsing/processing the winio@ line that contains the %og command. The (working) default of the fpu control word is 0x27f (all exceptions masked) whereas ftn95 changes this to 0x360 (all exceptions trigger an fpu exception) which lets the wglCreateContext (implicitly called by %og) to fail.

Please let me know if more information is needed, it would be nice to get response/verification of the issue soon as it effectively limits the use of ftn95-compiled OpenGL applications on current systems.

Thanks.

Sebastien,

I was hoping that you would have got a response by now. I have had issues with OpenGL as well, usually overcome by setting hardware acceleration off (it would be nice to do this from the program with calls to the registry settings if possible).

I was wondering if it could be possible to create an OpenGL graphics region without using %og ?

I found some code written for Compaq Visual Fortran to do this, could it be possible to get this to work with Silverfrost FTN95?

cheers, John

Module VarGlob
    integer:: hRC           ! Permanent Rendering Context
    integer:: hDC           ! Private GDI Device Context
    logical:: keys(0:255)   ! Array Used For The Keyboard Routine

End Module VarGlob

integer function WndProc( hwnd, message, wParam, lParam )
!DEC$ attributes stdcall :: WndProc

    use VarGlob

      include <clearwin.ins>,nolist
      include <opengl.ins>,nolist

    use dfwin
    use opengl_gl
    use opengl_glu
    use opengl_w

    implicit none

    integer hwnd
    integer message
    integer wParam
    integer lParam
    integer(GLuint) PixelFormat
    type(t_RECT) Screen
    TYPE (T_DEVMODE), Pointer :: DevMode_Null       ! *djip*** pointer null for comback...

    integer ignor, nColors
    integer glnWidth, glnLength

    integer  ipfd
    parameter (ipfd=or(or(   PFD_DRAW_TO_WINDOW,  &  ! Format Must Support Window
                             PFD_SUPPORT_OPENGL), &  ! Format Must Support OpenGL 
			                 PFD_DOUBLEBUFFER))      ! Must Support Double Buffering
    type (t_PIXELFORMATDESCRIPTOR)::pfd = t_PIXELFORMATDESCRIPTOR( &
    	40,			        &	! Size Of This Pixel Format Descriptor
	    1,			        &   ! Version Number (?)
	    ipfd,               &
	    PFD_TYPE_RGBA,		&	! Must Support Double Buffering
	    16,			        &	! Select A 16Bit Color Depth
	    0, 0, 0, 0, 0, 0,	&	! color bits ignord (?)
	    0,			        &	! no alpha buffer
	    0,			        &	! Shift Bit Ignored (?)
	    0,			        &	! no accumulation buffer
	    0, 0, 0, 0, 		&	! Accumulation Bits Ignored (?)
	    32,			        &	! 16Bit Z-Buffer (Depth Buffer)  
	    0,			        &	! no stencil buffer
	    0,			        &	! no auxiliary buffer
	    PFD_MAIN_PLANE,		&	! Main Drawing Layer
	    0,			        &	! Reserved (?)
	    0, 0, 0 )			    ! Layer Masks Ignored (?)


    select case (message)				    ! Tells Windows We Want To Check The Message
        case (WM_CREATE)
            hDC = GetDC(hwnd);              ! Gets A Device Context For The Window
            PixelFormat = ChoosePixelFormat(hDC, pfd)		! Finds The Closest Match To The Pixel Format We Set Above

            if (PixelFormat .eq. 0) then
                ignor = MessageBox(0, 'Can''t Find A Suitable PixelFormat.'C, 'Error'C, ior(MB_OK,MB_ICONHAND))  ! MB_ICONERROR=MB_ICONHAND and MB_ICONERROR do not existe in module  'dfwin.mod'
	            call PostQuitMessage(0)     ! This Sends A 'Message' Telling The Program To Quit
                return                      ! Prevents The Rest Of The Code From Running
            endif

            if (SetPixelFormat(hDC, PixelFormat, pfd) .eq. 0) then
                ignor = MessageBox(0, 'Can't Set The PixelFormat.'C, 'Error'C, ior(MB_OK,MB_ICONHAND))
 	            call PostQuitMessage(0)     ! This Sends A 'Message' Telling The Program To Quit
                return                      ! Prevents The Rest Of The Code From Running
            endif

here is the rest of the code:-

	        hRC = wglCreateContext(hDC);
            if (hRC.eq. 0) then
                ignor = MessageBox(0, 'Can't Create A GL Rendering Context.'C, 'Error'C, ior(MB_OK,MB_ICONHAND))
 	            call PostQuitMessage(0)     ! This Sends A 'Message' Telling The Program To Quit
                return                      ! Prevents The Rest Of The Code From Running
            endif
            if (wglMakeCurrent(hDC, hRC).eq. 0) then
                ignor = MessageBox(0, 'Can't activate GLRC.'C, 'Error'C, ior(MB_OK,MB_ICONHAND))
 	            call PostQuitMessage(0)     ! This Sends A 'Message' Telling The Program To Quit
                return                      ! Prevents The Rest Of The Code From Running
            endif
	        ignor = GetClientRect(hWnd, Screen)
			Call InitGL(Screen.right, Screen.bottom)
	        return

        case (WM_DESTROY)
        case (WM_CLOSE)
	        ignor = ChangeDisplaySettings(DevMode_Null, 0)

	        ignor = wglMakeCurrent(hDC, NULL)
	        ignor = wglDeleteContext(hRC)
	        ignor = ReleaseDC(hWnd,hDC)

            call PostQuitMessage(0)     ! This Sends A 'Message' Telling The Program To Quit

            return

        case (WM_KEYDOWN)
			keys(wParam) = .TRUE.
            return

        case (WM_KEYUP)
			keys(wParam) = .FALSE.
            return

        case (WM_SIZE)
			call ReSizeGLScene(LOWORD(lParam),HIWORD(lParam));
            return

        case default
            WndProc = DefWindowProc(hwnd, message, wParam, lParam)
            return
        end select
    return
end function WndProc

Using a custom setup like this may be possible but could create arbitrary problems with existing clearwin code, or issues with the current callback logic associated to the OpenGL window.

Disabling hardware acceleration (effectively using software emulation of OpenGL) is not an option either. What issues were you experiencing?

Thanks for your suggestions!

'What issues were you experiencing? '

program crashing when it attempted to fire up opengl, problem was I couldn't replicate the crash on any development machine of my own, only various clients laptops did this and only ever on laptops, so I wasn't able to do any debugging. I did post the problem in the forum at the time, but got nothing useful to help.

Posted in march, I'd like to have an official statement on this since users are switching to 64bit machines and telling them that the compiler doesn't support OpenGL on recent ATI cards won't necessarily increase happiness.

We are receiving reports from users with similar configurations (ATI graphics card model Radeon HD 5770, 5870 etc.) on Windows7 PCs, varying driver versions, that crash at program startup (OpenGL initialization). I'd really like to know if somebody is working on fixing this, and if additional information from our side shall be provided.

Affects 32bit XP as well, just in case if somebody was curious if his ftn95 OpenGL application will run on current ATI cards on some system (it doesn't).

We have been experiencing similar program hangs with one particular customer who has the following two new computers...

Dell Studio Win 7 Home Premium 64 bit, 4Gb RAM & ATI Mobility Radeon HD 5650 graphics

Dell Precision Workstation T5500 Win 7 Professional 64 bit, 8Gb RAM & ATI Firepro V4800 (FireGL)

Customer has all the latest drivers and everything else which might interfere is turned off.

Both fail to run any of the Silverfrost text programs 'Animate', 'Depthcue', 'Double', 'Stencil', or 'Teapots'. Three of them report 'Access Violations' while two of them simply hang.

All five programs run on 64-bit Win7 laptops at our office, but none of them has exactly the same architecture (we have either GeForce graphics or integrated graphics on all of our computers), though Win XP and Win Vista 32-bit computers here are okay.

We're on the latest released compiler.

Just to be clear on this ... this issue does affect 32-bit Window as well as 64-bit?

Nigel,

Did your customer try setting hardware acceleration off (via display in control panel) ?

As this usually fixes the problem when my software sees this problem.

John

Just to be clear on this ... this issue does affect 32-bit Window as well as 64-bit?

Yes.

The problem is in one of the window function handlers (usually WndProc) when CreateWindowExA is called (this is all internals of the %og window creation so fully out of our control). The function should be easily determinable by you since it's the one that calls wglCreateContext.

Did your customer try setting hardware acceleration off (via display in control panel) ?

Disabling hw acceleration is surely no option for high performance/large geometry/interactive OpenGL applications.

Sebastien,

I suggest you see for yourself if you get any noticeable hit on performance with h/w acceleration off.

John

I suggest you see for yourself if you get any noticeable hit on performance with h/w acceleration off.

Under XP it's noticeably sluggish for the relevant settings, under Win7 the hardware acceleration cannot be changed when using the ATI card and disabling the enhanced Win7 theming did not prevent the crash.

Quoted from JohnHorspool Nigel,

Did your customer try setting hardware acceleration off (via display in control panel) ?

As this usually fixes the problem when my software sees this problem.

John

Hi John, Windows 7 doesn't have a hardware acceleration option. We have turned off Aero and every other setting and none of it makes any difference.

Quoted from Robert Just to be clear on this ... this issue does affect 32-bit Window as well as 64-bit?

Haven't a clue. Problems currently on 64-bit with ATI as mentioned in my earlier post. I don't know of any customers who are buying 32-bit systems anymore.

Can you download this and run it:

http://www.silverfrost.com/public_downloads/wglCreateContext.exe

It will need salflibc.dll on the path. It checks that it can talk to the OpenGL subsystem. The traceback from lozzer suggested that maybe it couldn't see it.

Sebastian: are you still saying that it is a FP control word issue? I have stepped through the call that the above .exe makes and there are no FPCW changes. If the CW was being changed as you said it would cause a big problem.

I have stepped through the call that the above .exe makes and there are no FPCW changes.

It's the default fpu CW setting (is that even specified in the EXE/PE header??) of a ftn95 compiled executable which leaves the underflow exception unmasked. Thanks for looking into this!

It checks that it can talk to the OpenGL subsystem. The traceback from lozzer suggested that maybe it couldn't see it.

The call works fine here and returns a non-null address. In general there's no problem with the wglCreateContext functionality per se on these systems/ATI drivers, other OpenGL applications work fine, all have to create a context using this function.

Quoted from Robert Can you download this and run it:

http://www.silverfrost.com/public_downloads/wglCreateContext.exe

It will need salflibc.dll on the path. It checks that it can talk to the OpenGL subsystem. The traceback from lozzer suggested that maybe it couldn't see it.

Sebastian: are you still saying that it is a FP control word issue? I have stepped through the call that the above .exe makes and there are no FPCW changes. If the CW was being changed as you said it would cause a big problem.

I'm completely lost now. Is this program supposed to work on a client's PC? I've tried running it on mine and I get what appears to be a command box appearing very briefly and then it disappears.