Jogl Using Wrong (Generic) Graphics Adapter

On 11/27/2014 04:09 PM, Tobi Delbruck [via jogamp] wrote: I remember another user had this issue as well
and it was related to either exhausted GL context and/or GPU memory.

Then the ICD GL driver switched to the GDI 1.1 software renderer.

This is not a JOGL issue.

AFAIK the issue was resolved either by updating the driver,
or even by avoiding the number of GL context or GPU memory utilization.

~2000 context count, is what I remember .. hmm, not so sure.

The exception then is caused due to requesting a higher profile
than the ARB context creation method can serve (see above).
Even though, the returned context is only 1.1. It would throw an
exception later anyway, due to non-compliant context.

To test the above resource restriction, you can sample some heuristics
while creating context until catching the exception.
Please share your results - thank you!

~Sven

Thanks Julien, really appreciate your work on this. How can we contribute, e.g. financially?

First I need to get 2.2.4 so I can run the debug tools. We only have the runtime jars in our project and it is not clear from the instructions (at least to me) how to run the JOGL info applet. (Would be nice to see code snippet how this information could be output from our application.) Will post again once I can get this info.

Tobi

You're welcome. You should consider Sven's suggestion too because there is a small difference with my case, I was getting the same exception immediately whereas you get the same exception when more than one GLCanvas is created.

What is wrong with the applet? You can use the Java Web Start version, have you looked at this page in the top left corner, "JOGL Version Information"?
http://jogamp.org/deployment/jogamp-current/jogl-test-applets.html

By the way, the source code of the applet is here.

Feel free to contact Sven in private for any financial contribution, it helps to pay for the hardware, the bandwidth, the moves, ...

On 11/27/2014 04:09 PM, Tobi Delbruck [via jogamp] wrote:
We have no unit test using the 1st _defined_ GLCapabilitiesImmutable
from the 'available' pool, as you 'chose' yours above.
Note that those instances are specialized w/ native information,
e.g. WGLGLCapabilities is being returned/used.

It simply could be, that the 1st instance triggers to create a GLContext
using the GDI driver.

The recommended way is to pass your own GLCapabilities instance when creating
an [auto]drawable, while setting your desired properties.
E.g. if you request bitmap rendering,
you might also get a GDI context on Windows.

Then the GLCapabilities chooser will pick the proper
native pixelformat and produces a chosen GLCapabilities instance.

Hope this helps a bit.

~Sven

For what its worth, I am still seeing this same issue and this does seem to be the same.  I saw it on a ATI Graphics hardware, but if this user is seeing it on a Nvidia GeForce, maybe there is some other issue ( I believe WordWind user was seeing it on Nvidia) . In my case I had always passed a new GLCapabilities instance when creating my glcanvas. The problem I was seeing was happening somewhere before updateGraphicsConfiguration was being called because the native surface appeared to be the wrong one and was already defined with a pixel format. This then later caused the create context failure. What ever causes this problem, after the first time it happens, it continues to happens and you can never create another window/glcanvas without kill the application and restarting.

I am unable to change video hardware due to being an embedded system, so I'm still looking for some way to resolve this.  I am more then willing to do some addition testing on this issue. If there is any debug information needed or something you need to try I may be able to help.

Thanks
Steve

On 12/01/2014 03:06 PM, sfriend [via jogamp] wrote: Great progress triaging this issue.

If you haven't done yet, please create a new bug report
w/ all the details incl. your last findings.

Switching screens/monitor with AWT IMHO assumes using the same GPU
or at least the same driver capabilities.

This is due to 'big desktop' which spans to all connected monitors,
I have elaborated on this issue in the forum some time ago.

It would be great to have a unit test to reproduce this issue,
if anyhow possible, please copy one of our unit tests and adapt it
for this issue. A git pull request or patch would be most welcome.

~Sven

Thanks for the detailed instructions. I created Bug 1105 https://jogamp.org/bugzilla/show_bug.cgi?id=1105 to try to help. I can try to make a JUnit test but this would still require SVN checkout of jAER project. The bug is reproducible on several (but not all ) machines, all with NVIDIA GPUs and all using the latest driver 344.75.
Thanks again, Tobi

Hi

I know that it's not always trivial but please try to provide a test case without jAER for several reasons:
- it would be a definitive way of checking that the trouble comes from JOGL and not from jAER
- it would allow us to keep the JUnit test in our tests so that the fix won't get broken silently
- it would help us to reproduce and to fix the bug

The bug that I quoted was initially only reproducible in Java3D and sometimes some developers report some bugs against Ardor3D (now JogAmp's Ardor3D Continuation).

Anyway, thank you for your complete bug report. I have to spend some time in looking at the attachments.

I don't think I am creating that many contexts, but maybe I'm not getting it. Maybe 5 in total if you count
1. the initial dummy context
2. A first GLCanvas (this is actually called twice because of class hierarchy)

Now after this first canvas is realized on the display, I make a new window, which again creates two GLCanvas.
The exception is thrown then.

If the preferences of jAER are such that 2 GLCanvas are created on startup, there is no exception. The exception only occurs if the first canvas is created, then presumably displayed, and then another one is created and attempted to be displayed.
This is consistent with the problem being perhaps in the native window.

I also tried the recommended procedure below, both with and without shared context and using a variety of options for the GLCapabilities. Now what occurs is that the 2nd canvas does appear, but it is being rendered with GDI 1.1 and there are many artifacts, aside from being unusably slow.


               GLCapabilities caps=new GLCapabilities(GLProfile.getDefault());
                 caps.setDoubleBuffered(true);
                 caps.setHardwareAccelerated(true);
                 caps.setRedBits(8);
                 caps.setGreenBits(8);
                 caps.setBlueBits(8);
                caps.setAlphaBits(8);
                caps.setOnscreen(true);
               
                drawable = new GLCanvas(caps);

I will try to make a unit test to reproduce the behavior following https://jogamp.org/wiki/index.php/Contributing_a_new_feature_or_fix

Sven, let me know how we can financially contribute. This can come from research funding. JOGL has clearly been a major factor in allowing us to effectively demonstrate the silicon retina technology.
Tobi

On 12/03/2014 02:42 PM, Tobi Delbruck [via jogamp] wrote:
> I don't think I am creating that many contexts, but maybe I'm not getting it.
> Maybe 5 in total if you count
> 1. the initial dummy context
> 2. A first GLCanvas (this is actually called twice because of class hierarchy)

5 should not be an issue.
That would be great, i.e. most simple self containing unit test!

Ofc .. if the above leads to receiving a GDI 1.1 context,
this is a bug (probably the driver). We may need to find a workaround here.
The latter could be a custom GLCapabilitiesChoser .. or the like.

AFAIK you mentioned a 'special box', i.e. setup/machine,
it may be possible that this issue is only visible there ?!
Then we might need ssh access (Windows -> Cygwin) or a box shipped.

>
> Sven, let me know how we can financially contribute. This can come from
> research funding. JOGL has clearly been a major factor in allowing us to
> effectively demonstrate the silicon retina technology.

Sounds great, pls contact me or any other person via
one of the address you can find here:
  <http://jogamp.org/wiki/index.php/Maintainer_and_Contacts>

Besides funding (which is always great and important),
maybe further collaboration is possible ?

This goes for all research institutes/universities ofc.
  - Research Papers (PhD Positions ?)
  - Collaboration / Actual Work
  - Coordination of work

Of course, most of us here might already have all their hands full.

Thank you.

Cheers, Sven

> Tobi
>

I manged to clone gluegen and gogl after installing about 3 git tools, managed to start build in netbeans and am struggling now with installing some gcc on my win 7 x64 machine now, installer does not work and I have to try to work around that. Will update.

I managed to download the mingw binary for gcc finally and just added the unpacked archive to my PATH. Now gluegen and jogl can both build.

But I never used JUnit and the tutorials are very indirect about how to use it.
The example listed in the instructions https://jogamp.org/wiki/index.php/Contributing_a_new_feature_or_fix for a JOGL test has a broken link pointing to the gears test example.

Whenever I try to run an existing test, e.g. on  Bug427GLJPanelTest1 JUnit reports there is an error. I think this class is not a junit test.

gluegen has a directory src/test and gluegen has src/junit. Does this mean that JOGL does not have junit tests?

And do jogamp use JUnit 3 or JUnit 4?

Sorry for all these basic questions.

On 12/04/2014 04:20 PM, Tobi Delbruck [via jogamp] wrote:
> I managed to download the mingw binary for gcc finally and just added the
> unpacked archive to my PATH. Now gluegen and jogl can both build.
>
great.
Of course, we have alot in jogl/src/test/,
e.g. jogl/src/test/com/jogamp/opengl/test/junit/jogl/awt/

>
> And do jogamp use JUnit 3 or JUnit 4?

We use:
  gluegen/make/lib/junit.jar
which is a drop-in replacement of junit 4.8.2.
Read gluegen/make/lib/junit.LICENSE.txt

If using an IDE, you need to setup the compatible
junit jar files then!

+++

While it should be possible to use an IDE
to launch the unit tests, I run them via commandline.

Further, the repo provides my sandbox scripts
to launch selected unit tests manually
from the commandline.

POSIX, UNIX, OSX:
  jogl/make/scripts/tests.sh
  e.g. via
    jogl/make/scripts/tests-x64.sh

Windows:
  jogl/make/scripts/tests-win.bat
  e.g. via
    jogl/make/scripts/tests-x64.bat

>
> Sorry for all these basic questions.

No problem.

Hope it helps.

~Sven

Just an update: No progress yet in understanding how to make a JUnit test case for this bug. Could you perhaps point me to the closest example that I could start from?
I also have the practical problem of integrating JUnit into netbeans, but I can try to figure that out. I mean that the JUnit classes are not recognized in netbeans even though JUnit module is installed and I have added the JOGL JUnit jar to the lib folder for JOGL by copying it from gluegen. How the classpath is derived is not so obvious from this "freeform" ant build.xml.
Somehow just copying the junit.jar to the folder does not make it appear in the project classpath.
(I can try to figure out this part).
Tobi

I finally tracked down the bug cause in jAER, or at least a contributing source.

jAER uses a WindowSaver class to store (on Runtime shutdown hook) and restore (via Toolkit window open event) active window sizes and locations. This WindowSaver restores the window position by being automagically called by the window opening event.

If this class is disabled by not registering the AWTEventListener, the dropback to GDI problem goes away along with the exceptions.

No idea why this might be occurring.

My listener install code:

       final WindowSaver windowSaver = new WindowSaver(null, prefs);
        Toolkit.getDefaultToolkit().addAWTEventListener(windowSaver, AWTEvent.WINDOW_EVENT_MASK); // adds windowSaver as JVM-wide event handler for window events


The WiindowSaver method loadSettings that positions and resizes the window that has just been opened, taking account of screen Insets (like the windows taskbar that typically is at bottom of screen)

    /** The preferred settings are loaded based on window name.
     * A windows which would be displayed partly off-screen is moved to originate at 0,0.
    A window which would be too tall or wide is resized to screen size.
    @param frame JFrame to load settings for
     */
    public void loadSettings(JFrame frame) throws IOException {
        boolean resize=false; // set true if window is too big for screen
        String name=frame.getTitle().replaceAll(" ", "");

        int x=preferences.getInt(name+".x", 0);
        int y=preferences.getInt(name+".y", 0);
        int w=preferences.getInt(name+".w", DEFAULT_WIDTH);
        int h=preferences.getInt(name+".h", DEFAULT_HEIGHT);
        if(w!=DEFAULT_WIDTH|h!=DEFAULT_HEIGHT) {
            resize=true;
        }
        Dimension sd=Toolkit.getDefaultToolkit().getScreenSize();

        // determine the height of the windows taskbar by this roundabout proceedure
        // TODO tobi removed this because it was causing a runtime native code exception using NVIDIA 181.22 driver with win xp
        // replaced by hardcoded lowerInset
//        lowerInset=64;
        GraphicsEnvironment ge=GraphicsEnvironment.getLocalGraphicsEnvironment();
        GraphicsDevice[] gs=ge.getScreenDevices(); // TODO it could be that remote session doesn't show screen that used to be used. Should check that we are not offscreen. Otherwise registy edit is required to show window!

        if(gs!=null&&gs.length>0) {
            if(gs.length>1){
//                log.info("There are "+gs.length+" GraphicsDevice's found; using first one which is "+gs[0].getIDstring());
            }
            GraphicsDevice gd=gs[0];
            GraphicsConfiguration[] gc=gd.getConfigurations();
            if(gc!=null&&gc.length>0) {
                if(gc.length>1){
//                    log.info("There are "+gc.length+" GraphicsConfiguration's found; using first one which is "+gc[0].toString());
                }
                Insets insets=Toolkit.getDefaultToolkit().getScreenInsets(gc[0]);
                lowerInset=insets.bottom;
            }
        }

        if(x<0){
            log.info("window x origin is <0, moving back to zero");
            x=0;
        }
        if(y<lowerInset){
            log.info("window y origin is < lowerInset, moving back to "+lowerInset);
            y=lowerInset;
        }
        if(x+w>sd.width||y+h>sd.height) {
            log.info("window extends over edge of screen, moving back to origin");
            x=y=0;
        }
        if(h>sd.height-lowerInset) {
            log.info("window height ("+h+") is bigger than screen height minus WINDOWS_TASK_BAR_HEIGHT ("+(sd.height-WINDOWS_TASK_BAR_HEIGHT)+"), resizing height");
            h=sd.height-lowerInset;
            resize=true;
        }
        if(w>sd.width) {
            log.info("window width ("+w+") is bigger than screen width ("+(sd.width)+"), resizing height");
            w=sd.width;
            resize=true;
        }
        // check for last window with same name, if there is one, offset this one by OFFSET_FROM_SAME
        if(framemap.containsKey(name)) { // we had a frame already with this name
            int offset=lastframemap.containsKey(name)?lastframemap.get(name):0;
            offset+=OFFSET_FROM_SAME;
//            Insets insets=frame.getInsets();
            x+=offset;//+insets.left;
            y+=offset;//+insets.top;
            lastframemap.put(name, offset);
        }
        frame.setLocation(x, y);
        if(resize&&!(frame instanceof DontResize)) {
            frame.setSize(new Dimension(w, h));
        }
//        log.info("loaded settings location for "+frame.getName());
        framemap.put(name, frame);
        frame.validate();
    }

I will investigate some more, and should be able to make a test case.

I now isolated the cause down to the call below

            GraphicsDevice gd=gs[0];
            GraphicsConfiguration[] gc=gd.getConfigurations();
            if(gc!=null&&gc.length>0) {
                if(gc.length>1){
//                    log.info("There are "+gc.length+" GraphicsConfiguration's found; using first one which is "+gc[0].toString());
                }
                Insets insets=Toolkit.getDefaultToolkit().getScreenInsets(gc[0]);
                lowerInset=insets.bottom;
            }

If I remove this determination of the lowerInset (the Taskbar, on Windows 7) the problem goes away; no more GDI rendering. Commenting out this call for lowerInset also solves the problem in jAER itself.

Not sure if this helps. I can copy this over to the bug report or else wait until I can make a test case.

Good job. It looks weird to me but it will be easier to understand with a small test case.

Edit.: Maybe the use of a particular graphics configuration forces the use of GDI rendering :s

Finally some progress, not in making a JUnit test case but in solving the problem.

First, the problem of dropping back to software rendering was solved by replacing the call to retrieve the screen insets by the following:

       Dimension sd = Toolkit.getDefaultToolkit().getScreenSize();

        // determine the height of the windows taskbar by this roundabout proceedure
        // TODO tobi removed this because it was causing a runtime native code exception using NVIDIA 181.22 driver with win xp
        // replaced by hardcoded lowerInset
        lowerInset = 64;

        Rectangle windowBounds = GraphicsEnvironment.getLocalGraphicsEnvironment().getMaximumWindowBounds();
        if (windowBounds != null) {
            lowerInset = sd.height - windowBounds.height;
        }


Secondly, I finally realized that I was doing what should not be done but is hard to catch: Running Swing/AWT code outside the Swing thread. I replaced the WindowSaver code that actually resizes the window with a call to Swing.invokeLater():

       final boolean resize2 = resize;
        final int w2=w, h2=h, x2=x, y2=y;
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                frame.setLocation(x2, y2);
                if (resize2 && !(frame instanceof DontResize)) {
                    frame.setSize(new Dimension(w2, h2));
                }
//        log.info("loaded settings location for "+frame.getName());
                framemap.put(name, frame);
                frame.validate();
            }
        });

Now I don't have the problems anymore. However the root of the original problem, which was caused by the call to
//                GraphicsConfiguration[] gc = gd.getConfigurations();
remains mysterious.

I'll see how this works on various machines and report back if anything new comes up.
Tobi