Aardwolf's picture

GLContext.SwapBuffers hangs on x64

Project:The Open Toolkit library
Version:1.0-beta-2
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:open
Description

This issue occurred after installing on a new laptop with Windows 7, but did not occur on an older x86 machine running Windows XP (with an Intel 950 GMA)...

Specifically the one that didn't work: Windows 7 (64-bit), with an ATI Mobility Radeon HD 4670 (1GB)

Initially the problem seemed to manifest itself as a GraphicsContextMissingException (which did not occur on the XP/Intel laptop), which was eliminated by putting in some guards against GL calls prior to load (which needed 1.0-beta-2 to work)...

Then however, my application still did not work; the SwapBuffers method of the GLControl class caused the program to hang ("block"). After trying various things to ascertain what the problem was, I was eventually able to fix it by building the project for the x86 platform.

So it doesn't seem to work on x64 machines.


Comments

Comment viewing options

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

#1

Thanks for the bug report. Do the GLControl examples that come with OpenTK exhibit this issue? If not, can you please post a simple test case that reproduces this issue?

The output of the following commands would also help:

GL.GetString(StringName.Vendor);
GL.GetString(StringName.Renderer);
GL.GetString(StringName.Version);
Aardwolf's picture

#2

The OpenTK/OpenGL examples fail on line 338 of ExampleBrowser.cs,

Thread thread = new Thread((ThreadStart)delegate { main.Invoke(null, null); });

With an unhandled TargetInvocationException... the inner exception reads "Attempted to read or write protected memory. This is often an indication that other memory is corrupt." ... there appears to be a try/catch block for this, but the debugger never reaches it. Nonetheless, if run without debugging, most of the examples seem to work properly.

None of them exhibited this issue, however.

the Fiddler's picture

#3

Thanks, which catalyst version are you using?

Aardwolf's picture

#4

Hm... "Catalyst Control Center Version" says "2009.0625.1812.30825", is that it?

the Fiddler's picture

#5

Thanks. Catalyst Control Center should also mention a simpler version number in the form "9.10" or similar (this is year.month), which might be useful in diagnosing the issue. In any case, it might be a good idea to install the latest drivers from http://www.amd.com.

My Ati/Win7 system is offline right now (hard drive crash), so I cannot test with a similar configuration. However, everything seems to work fine on Nvidia/Win7 and Intel/Win7 (both 64bit), so this might be driver related. I'll try to reproduce as soon as I get the system back online.

the Fiddler's picture

#6

I cannot reproduce this on my Win7 system (Windows 7 64bit Professional, Catalyst 10.01, Ati 4850 video card). Can you please install the latest drivers from http://ati.amd.com and see whether the problem persists?

the Fiddler's picture

#7

Status:open» need info
Aardwolf's picture

#8

Oops, almost forgot about this.

Unfortunately, I can't download the latest drivers because ATI's website doesn't even offer them; some reason, they think us Windows 7 users don't matter

the Fiddler's picture

#9

Status:need info» open

All right, let me see if I can reproduce this by uninstalling my video drivers.

Normally, you have to download drivers from laptop vendors (who don't bother to update very often) or mod Ati's regular drivers to install them (via modtool). It is said that Ati will finally start offering mobile drivers directly, beginning this March. Let's see!

the Fiddler's picture

#10

Priority:critical» normal

I haven't been able to reproduce this issue. Removing my drivers and letting windows update handle the task results in OpenGL 1.1 support (GDI renderer), not the D3D emulator.

If someone can reproduce it please make a post so we can devise a methodology to find the cause and fix it. While serious, I don't feel this issue is worth delaying the 1.0 any longer (reducing priority).