Long shot- ATI Radeon Mobility 7500 and windowed mode corrupts screen

[corwin_lw]

I have two different machines- both Fujitsu laptops with ATI Radeon Mobility 7500. On both of these machines, if I open a number of OpenGL windows, after a few of them it starts drawing on the desktop background, the window menu bars, et-cetera. The number of windows appears to scale with the memory on the card- on a 16 meg card, the second window causes corruption, whereas on a 32 meg card it goes up to 8 windows.

There aren’t any newer drivers for this machine. This works on a wide variety of hardware, Macs, PCs, Linux- only this hardware fails like this.

I’m totally desperate. Normally, on other projects, I’d just give up and say that hardware wasn’t supported. Sadly, this is the bosses’ machine, and it seems unreasonable to him that it might not work. Any help would be greatly appreciated- I’d sing your praises from the heavens if it worked.

[kbr]

Does this happen with any OpenGL application or only JOGL apps?

Try specifying -Djogl.GLContext.nofree on the command line (documented in the JOGL User’s Guide). This workaround was added for bugs in ATI’s drivers on Radeon Mobility 9700 hardware. Does this change or improve the behavior?

Have you upgraded the drivers to ATI’s latest? Some problems we worked around in JOGL were fixed in one of the recent Catalyst releases.

[corwin_lw]

@Ken Russell

Does this happen with any OpenGL application or only JOGL apps?

Apparently only on JOGL apps.

@Ken Russell

Try specifying -Djogl.GLContext.nofree on the command line (documented in the JOGL User’s Guide). This workaround was added for bugs in ATI’s drivers on Radeon Mobility 9700 hardware. Does this change or improve the behavior?

This has no effect on the behavior.

@Ken Russell

Have you upgraded the drivers to ATI’s latest? Some problems we worked around in JOGL were fixed in one of the recent Catalyst releases.

Do the Catalyst drivers work on Mobility products? My understanding was that they only work on desktop products. That’s what ATI’s website seems to imply. I thought that laptop cards would need manufacturer drivers.

[kbr]

@corwin_lw

Do the Catalyst drivers work on Mobility products? My understanding was that they only work on desktop products. That’s what ATI’s website seems to imply. I thought that laptop cards would need manufacturer drivers.

Good point. Have you checked your vendor’s web site to see if there is a more recent driver release available?

Can you boil down the problem into a small test case?

What other non-JOGL OpenGL apps have you tried? Have you tried modifying the simple GLUT Gears demo to open multiple windows to prove that the problem is in the JOGL layer rather than at the OpenGL layer?

[corwin_lw]

Ok, more info. I’ve verified that after creating and destroying windows, I can then clear the GLCanvases and such, close all the windows, and then opening a new window will be screwed up. Additionally, other apps’ OpenGL contexts are corrupt, and dxdiag reports “Out of video memory” when trying to run the Test Direct3D option. It seems like the following things are happening:

• JOGL maybe isn’t paying attention to whether or not it’s getting back a good context, with enough memory and such.
• JOGL isn’t freeing the GL contexts when it’s done with them.

Any tips? Am I totally wrong?

[corwin_lw]

@Ken Russell

Have you checked your vendor’s web site to see if there is a more recent driver release available?

As I said originally, there are no newer drivers available, sadly.

@Ken Russell

Can you boil down the problem into a small test case?

I have no idea. Quite possibly. But as I mentioned above, it only happens on this hardware, so unless you had said hardware, I doubt it would do you much good.

@Ken Russell

What other non-JOGL OpenGL apps have you tried? Have you tried modifying the simple GLUT Gears demo to open multiple windows to prove that the problem is in the JOGL layer rather than at the OpenGL layer?

I’ve tried our C++ OpenGL version, as well as dxdiag (I know, it’s not GL, but it has trouble) and I’ve also run GLExcess. Once I’ve opened windows in the JOGL app, all those apps fail in one way or another, in ways that might point to low memory.

This is likely a driver issue, I know, but I still am surprised by the fact that JOGL doesn’t seem to free GL contexts and doesn’t seem to check errors given from wgl.

[kbr]

@corwin_lw

This is likely a driver issue, I know, but I still am surprised by the fact that JOGL doesn’t seem to free GL contexts and doesn’t seem to check errors given from wgl.

Are you running the latest JOGL build (1.1.1, July 12, from the Documents & Files section of the JOGL web page)? What is the output of java -Djogl.verbose demos.printext.PrintExt?

JOGL frees all of the GL contexts it creates (assuming the window is closed rather than simply exiting the application) and not only does it check all errors produced from WGL, it throws Java exceptions if they occur.

I don’t think the scenario you’re described has narrowed down the problem enough. If you write a simple JOGL program which opens up say 8 windows containing GLCanvases which have a no-op GLEventListener added, does the problem occur?

[Alan_W]

Might be same underlying driver problem as this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4713003
It starts off talking about 7200, but moves on to 7500 later and mentions the 8 contexts problem albeit w.r.t. directX

I have attached a test case which is a purely native app that shows the
problem. Apparently the problem is that we create too many d3d devices.
Currently, whenever we want d3d capabilities on a ddraw surface, we create
a d3d device for that surface. The DirectX docs suggest that having one
d3d device per ddraw object (not per ddraw surface) is a better way to
go for performance reasons; the context switching inherent in multiple d3d
devices is too expensive. They do not happen to mention that having too many
devices can also hang the system (this is presumably a driver bug that we
just happened to bump into on these ATI boards).

Although the real fix for the crash lies with ATI (I don’t think the OS
should crash because of what we are doing), we can and should fix the problem
in our code by moving to a system of sharing a single d3d device, as suggested
by the DirectX documention.

There are issues with this approach, such as:
- we need to do a SetRenderTarget whenever we are rendering into
a new ddraw surface since the single d3d device may currently be
set to a different render target.
- in addition to changing the rendering target, we also need to
update the viewport if the dimensions of the new surface differ
from the previous one.
- we need to lock around accesses to this shared device since we
have potential multi-threaded rendering issues when rendering to
different surfaces.

The test case (4713003.ManyD3dDevices.zip.Z) is a zipped project file from
a DevStudio application. You can either run the app in the Debug folder
directly or build the application and run it within DevStudio.
By changing the “NUM_OFFSCREEN_SURFACES” variable at the top of
DDHelloWorld.cpp you can affect the crash. I found that the crash only
occurred when this value was greater than 8 (the value is currently set to
9 in that file).

[corwin_lw]

@Ken Russell

Are you running the latest JOGL build (1.1.1, July 12, from the Documents & Files section of the JOGL web page)? What is the output of java -Djogl.verbose demos.printext.PrintExt?

I am running the latest build. Where can I download the demos.printext.PrintExt class?

@Ken Russell

JOGL frees all of the GL contexts it creates (assuming the window is closed rather than simply exiting the application) and not only does it check all errors produced from WGL, it throws Java exceptions if they occur.

I looked at the source and it would appear that it does report errors. However it still doesn’t seem like it’s deleting contexts- is there a way I can get at it directly and order it to go away?

@Ken Russell

I don’t think the scenario you’re described has narrowed down the problem enough. If you write a simple JOGL program which opens up say 8 windows containing GLCanvases which have a no-op GLEventListener added, does the problem occur?

Yes, yes it does.

[kbr]

@corwin_lw

I am running the latest build. Where can I download the demos.printext.PrintExt class?

It’s in jogl-demos.jar.

@corwin_lw

I looked at the source and it would appear that it does report errors. However it still doesn’t seem like it’s deleting contexts- is there a way I can get at it directly and order it to go away?

Under what conditions? If you close one of the windows the context will be deleted. If you run with -Djogl.debug.GLContext you will see reports printed when GLContexts are created and destroyed.

JOGL doesn’t do any magic under the covers with attempting to share one OpenGL context between multiple windows. If you request that 8 GLCanvases be opened, 8 OpenGL contexts will be created.

@corwin_lw

@Ken Russell

I don’t think the scenario you’re described has narrowed down the problem enough. If you write a simple JOGL program which opens up say 8 windows containing GLCanvases which have a no-op GLEventListener added, does the problem occur?

Yes, yes it does.

I’d be curious to know if the same program written using LWJGL’s AWTGLCanvas fails in the same way. Do you have the time to write this test program? If not, let me know and I’ll write it and send it to you.