Radeon 9800 XL experiences?

OpenGL Development JOGL Development
#1

A small Jogl application of mine does work fine on a Window box with Ati Radeon 9600 as well as on one with a Nvidia Geforce4. No fancy OpenGL stuff, just plain textured polygons.
However when I’ve tried to run it on another WinXP box with Ati Radeon 9800 XL, just the first frame has been rendered, the fps rate went down to 1 and the render loop “somehow” stood still: no GLCanvas redraw, but no error messages also (the DebugGL object has been enabled), nothing…

Unfortunately it’s not been a development machine so I hadn’t any chance to find out (in a hurry) what has been happening.
The very same effect I’ve seen with my small Xith application using the same Jogl version on that weird PC.

The Jogl version has been from 29th April 2004. The PC has got Catalyst v4.60. Directx9 demos/games run fine.

Has anybody seen something similar? How would you encircle the problem when the PC is far away from you and the guy using it has not the slightest idea of what OpenGL is, let alone Java?
Is there an OpenGL/Jogl test suite to see when the redraw fails?

PS: I know Ati’s drivers aren’t the best when it comes to OpenGL (they tend to just support what it needs to run ID’s Quake3 engine). Unfortunately this is of no help to me in that case… :frowning:

#2

Isolate driver trouble first: does Alien Flux run on this machine? If it works fine, you know the drivers are kosher, and can start looking at JOGL context problems.

Cas :slight_smile:

#3

[quote]Isolate driver trouble first: does Alien Flux run on this machine? If it works fine, you know the drivers are kosher, and can start looking at JOGL context problems.
[/quote]
Ok, thanks for that hint.
The good news: Your Alienflux runs on the guy’s PC.
Now I’ve to find out why my Jogl and Xith app doesn’t… Frankly I’ve no idea where to start searching.

#4

You may have run into a higher level problem with the code initialisation order. JOGL requires some very specific ordering of instructions otherwise a lot of stuff just fails to even get going. For example, don’t try to add the GLCanvas before the main Frame has been made visible, etc. What this ends up translating to is that the GLContext may be available on one card before it is on another, so code that works on one machine doesn’t work on another.

#5

[quote]JOGL requires some very specific ordering of instructions otherwise a lot of stuff just fails to even get going. For example, don’t try to add the GLCanvas before the main Frame has been made visible, etc.
[/quote]
Is there a list of GOTCHAs such as this documented somewhere?

#6

Not that I’m aware of. I’ve been accumulating a few of them to put into a FAQ. Right now, I’m trying to decide whether I should expand the existing Java3D FAQ to include JOGL and others (eg LWJGL to make it Java 3D) or if I should start another separate FAQ specifically for JOGL.

#7

Have you tried the JOGL 1.1 beta 04 release that was just posted? Please see the top thread in the forums for a pointer to it. It contains a workaround for multithreading-related bugs in ATI’s drivers that have been problematic in the past.

The gotchas about initialization order of JOGL calls (i.e., whether the Frame is shown before the animator starts, etc.) are bugs in JOGL that application writers have been working around for a while. I think the 1.1 beta 04 release may actually fix a couple of these bugs so please give it a try and post to let us know whether any of your problems have been addressed. If not then please file an Issue and attach a test case if at all possible.

#8

[quote]The gotchas about initialization order of JOGL calls (i.e., whether the Frame is shown before the animator starts, etc.) are bugs in JOGL that application writers have been working around for a while. I think the 1.1 beta 04 release may actually fix a couple of these bugs so please give it a try and post to let us know whether any of your problems have been addressed. If not then please file an Issue and attach a test case if at all possible.
[/quote]
No, 1.1b4 does not solve the order issue on the two ATI cards I have. The bug was introduced (for my hardware) in 1.1b01.

#9

Could you please file an issue on the JOGL web page and provide a small test case? Thanks.

#10

Sure, if you can clarify this issue. I may have muddied things because of doing fullscreen. When entering fullscreen, should the canvas be attached to the frame or should that wait until after fullscreen initialization.

Order doesn’t seem to matter in windowed mode. Is that expected behavior?

For example, I had to move the frame.getContentPane().add(glCanvas, BorderLayout.CENTER);
 call in the following bit of code:


public GLDisplay(String title, int width, int height, boolean fullscreen) {
        glCanvas = GLDrawableFactory.getFactory().createGLCanvas(new GLCapabilities());
        glCanvas.setSize(width, height);
        glCanvas.setIgnoreRepaint(true);

        frame = new JFrame(title);
        frame.getContentPane().setLayout(new BorderLayout());
        //frame.getContentPane().add(glCanvas, BorderLayout.CENTER);

        addKeyListener(new MyShutdownKeyAdapter());

        this.fullscreen = fullscreen;
        this.width = width;
        this.height = height;
        animator = new FPSAnimator(glCanvas, 60);
    }

public void start() {
        Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
        frame.setSize(width, height);
        frame.setLocation(
                (screenSize.width - frame.getWidth()) / 2,
                (screenSize.height - frame.getHeight()) / 2
        );
        frame.addWindowListener(new MyShutdownWindowAdapter());

        if (fullscreen) {
            frame.setUndecorated(true);
            usedDevice = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
            usedDevice.setFullScreenWindow(frame);
            usedDevice.setDisplayMode(
                    findDisplayMode(
                            usedDevice.getDisplayModes(),
                            width, height,
                            usedDevice.getDisplayMode().getBitDepth(),
                            usedDevice.getDisplayMode().getRefreshRate()
                    )
            );
        } else {
            frame.setVisible(true);
        }

        frame.getContentPane().add(glCanvas, BorderLayout.CENTER);
        glCanvas.requestFocus();

        animator.start();
    }
#11

The canvas should be added to the frame first, in both situations as far as I can tell. The frame should also be shown before making it the full-screen window. You should also specify -Dsun.java2d.noddraw=true on the command line when using full-screen mode to avoid driver conflicts between OpenGL and Java2D’s use of DirectDraw by default. I have heard of and seen some problems where the full-screen window doesn’t get resized properly on Windows when this system property is set, but I’ve heard that there are workarounds like re-setting the window’s size after full-screen mode is entered.

#12

[quote]You should also specify -Dsun.java2d.noddraw=true on the command line when using full-screen mode to avoid driver conflicts between OpenGL and Java2D’s use of DirectDraw by default. I have heard of and seen some problems where the full-screen window doesn’t get resized properly on Windows when this system property is set, but I’ve heard that there are workarounds like re-setting the window’s size after full-screen mode is entered.
[/quote]
That sounds like another bug. And I’ve seen that behavior on my GeForce2-GO when the noddraw flag is set. Yet it behaved properly without the flag. I’ve not tried that flag on either of my ATI cards.

Managing all of these different flags is worrying. How am I going to have confidence that someone downloading my app is going to be able to run it successfully?

While trying to recreate the order problem, I think 1.1b04 (July 16th) resolved the issue. At least, it has for the ATI Rage 128 as I cannot now reproduce it. I’ll verify I get the same behavior on the Radeon Mobility 9600 this evening. Downgrading to 1.1b04 build on 7/2/04 shows the problem existed then. But I also notice that I am getting the Microsoft driver in that case and not the ATI ICD.

So at this point, I think the ordering bug was coincidentally resolved or an artifact of the driver. I’ll keep testing and file something if I can reproduce it on different hardware with the current (July 16th) jogl.