GLContext version...

Hi,

I have upted version of JOGL from the one that was a couple of months old to the current one.

In CLContext the old isGL3() method looked like this:

  public final boolean isGL3() {
      return ctxMajorVersion>=3 && 0!=(ctxOptions & (CTX_PROFILE_COMPAT|CTX_PROFILE_CORE));
  }

I am using GL3.3 functionality in my code and my app was running fine.

In current JOGL version the mentioned method looks like this:

  public final boolean isGL3() {
      return ( ctxMajorVersion>3 || ctxMajorVersion==3 && ctxMinorVersion>=1 )
             && 0 != (ctxOptions & CTX_IS_ARB_CREATED)
             && 0 != (ctxOptions & (CTX_PROFILE_COMPAT|CTX_PROFILE_CORE));
  }

and returns false and thus breaks my application.

What's interesting is that while I am positive I am running OpenGL 3.3 capable nvidia drivers, the GLContext ctxVersionString field has value = "3.0 (compatibility profile, any, old) - 3.3.0" meaning the ctxMinorVersion=0 (-> false), even though the OpenGL version string states "3.3.0".
The second thing is that my ctxOptions field has value 34 and so fails the test for CTX_IS_ARB_CREATED (-> false).

When I manually override this two checks, the application starts, the shaders compile, but then I almost immediately get OpenGL "Out of memory" error, so something must be wrong with the context initialization...
In the mean time the same app running on the mentioned older version of JOGL is running fine, and GPU-Z is showing no memory leaks...

I would appreciate any help with this problem...

Thanks,
Mat

Sorry for the double post but...

It is getting more odd. After few failed attempts I just tried running the app once again and it went on smoothly, showing no errors at all. I actually cannot reproduce the out of memory OpenGL error... weird, as no other apps were run in the mean time...

Anyway the problem with GLContext version stays open. :(

On Wednesday, January 26, 2011 01:47:55 Mat [via jogamp] wrote:
Look here ..

http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/acore/TestGLProfile01NEWT.java;h=88caed35718b26a010824074cdd28333758d043c;hb=HEAD#l94

when creating the context,

http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/acore/TestGLProfile01NEWT.java;h=88caed35718b26a010824074cdd28333758d043c;hb=HEAD#l140

You pass the GLCapabilities instance, which has-a GLProfile.
In your case, just make sure you use IE the max programmable one, or fixed GL3.

~Sven

--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1

Hi Sven,

Thanks for prompt answer.

My code looks like this:

                GLProfile glp = GLProfile.getMaxProgrammable();
                System.err.println("GLProfile getMaxProgrammable(): "+glp);
                 
                GLDrawableFactory factory = GLDrawableFactory.getFactory(GLProfile.get(GLProfile.GL3));
                this.context = factory.createExternalGLContext();
               
                System.err.println(context.toString());

And the two prints look like this:

1)
GLProfile getMaxProgrammable(): GLProfile[GL3/GL3]

2)
com.jogamp.opengl.impl.windows.wgl.WindowsExternalWGLContext [OpenGL 3.0, options 0x22, 3.0 (compatibility profile, any, old) - 3.3.0, handle 0x20000, com.jogamp.opengl.impl.gl4.GL4bcImpl@422ede,
        Drawable: com.jogamp.opengl.impl.windows.wgl.WindowsExternalWGLContext$Drawable[Realized true,
        Factory   com.jogamp.opengl.impl.windows.wgl.WindowsWGLDrawableFactory@112f614,
        handle    0x69012ab4,
        Window    ProxySurface[config WindowsWGLGraphicsConfiguration[DefaultGraphicsScreen[DefaultGraphicsDevice[type Windows, connection decon, unitID 0, handle 0x0], idx 0], pfdID 8, ARB-Choosen true,
        requested GLCapabilities[Capabilities[Onscreen: true, Red: 8, Green: 8, Blue: 8, Alpha: 8, Opaque: true], GL profile: GLProfile[GL2/GL2], PBuffer: true, DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16, Multisample: false, Num samples: 0, PBuffer-FloatingPointBuffers: true, PBuffer-RenderToTexture: false, PBuffer-RenderToTextureRectangle: false],
        chosen    GLCapabilities[Capabilities[Onscreen: true, Red: 8, Green: 8, Blue: 8, Alpha: 8, Opaque: true], GL profile: GLProfile[GL2/GL2], PBuffer: true, DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16, Multisample: false, Num samples: 0, PBuffer-FloatingPointBuffers: true, PBuffer-RenderToTexture: false, PBuffer-RenderToTextureRectangle: false]], displayHandle 0x0, surfaceHandle 0x69012ab4, size 0x0]]]



So I do not see a way to programatically get anything higher than 3.0 (compatibility profile, any, old) - 3.3.0 on my machine.
This profile should allow me to use context.getGL().getGL3() method, am I correct or am I missing something?

  On 01/26/2011 09:58 PM, Matt [via jogamp] wrote:
> So I do not see a way to programatically get anything higher than 3.0
> (compatibility profile, any, old) - 3.3.0 on my machine.
> This profile should allow me to use context.getGL().getGL3() method
yes, exactly
> , am I
> correct or am I missing something?

-michael

--
http://michael-bien.com/

Michael Bien wrote

  On 01/26/2011 09:58 PM, Matt [via jogamp] wrote:
> So I do not see a way to programatically get anything higher than 3.0
> (compatibility profile, any, old) - 3.3.0 on my machine.
> This profile should allow me to use context.getGL().getGL3() method
yes, exactly
> , am I
> correct or am I missing something?

-michael

Well,
then going back to my first post in this topic:
"3.0 (compatibility profile, any, old) - 3.3.0" means ctxMajorVersion = 3 and ctxMinorVersion = 0
This alone makes the isGL3() method return false according to its current implementation... and I am wondering if (and why) this is proper behavior?

Thanks,
Matt.

On Wednesday, January 26, 2011 21:58:11 Matt [via jogamp] wrote:
There are only 2 factories, the native GLX/WGL/CGL one
and the EGL one. This is not the point.

The point is to create the GLAutoDrawable with the proper GLCapabilities/GLProfile instance.

http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/awt/TestAWT01GLn.java;h=83561eb9751f66cbb45d411caee0b1257218a4aa;hb=HEAD#l126
(line 126)

http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/awt/TestAWT01GLn.java;h=83561eb9751f66cbb45d411caee0b1257218a4aa;hb=HEAD#l85

> And the two prints look like this:

showing you have GL3 supported, good.

~Sven

Sven,

I am actually using SWT, so I have no GLAutoDrawable instance, I am using SWT's GLCanvas.

And well, after some debugging, here's what's going on:

As I mentioned, my external GLContext I am using has version string: "3.0 (compatibility profile, any, old) - 3.3.0", the very first two digits being its major and minor version, and preventing me from using getGL3(), as 3.1 is required.
And actually the created external context originally has version 3.3, but it is being downgraded in the GLContextImpl's setContextVersion(int major, int minor, int ctp) method:

// We cannot promote a non ARB context to >= 3.1,
// reduce it to 3.0 then.
if ( ( ctxMajorVersion>3 || ctxMajorVersion==3 && ctxMinorVersion>=1 )
     && 0 == (ctxOptions & CTX_IS_ARB_CREATED) ) {
    ctxMajorVersion = 3;
    ctxMinorVersion = 0;
}

so flag CTX_IS_ARB_CREATED is unset, and this is because of the constructor WindowsExternalWGLContext and its line:
setGLFunctionAvailability(false, 0, 0, CTX_PROFILE_COMPAT|CTX_OPTION_ANY);
of course manually adding flag CTX_IS_ARB_CREATED there does not result in anything good :) in my case it results in enabling the run of the application, but with 1000 times drop in fps, and total mess up in opengl contexts even for other instances of the app previously working correctly :)

Anyway, does this strictly mean that one cannot create external GLContext that would support opengl 3.1+ ?
If so, then am I forced to use Newt or Awt glcanvas? I read that Newt component is planned to replace the original SWT's GLCanvas. I could try to help with that, but need some info on the matter :)

Matt.

I'll try OpenGL 3.3 with SWT tomorrow and see if it works for me.

I remind you that we are not responsible of the bugs of SWT OpenGL binding. I have already provided an example of Eclipse RCP plugin using SWT (of course) and the JOGL GLCanvas. Wade already provides a simple example, do you need something more?

Actually, as I mentioned in Wade's thread, the only drawback of JOGL's GLCanvas is its inferior performance compared to SWT's original canvas. But I think I will sacrifice those few fps in order to save myself the nerves... and switch to JOGL's canvas. :-)
I appreciate all your help and examples.

Matt.

The JOGL GLCanvas is as fast as SWT GLCanvas when used correctly but more reliable (there is still an impacting bug...).

On Friday, January 28, 2011 14:17:26 Matt [via jogamp] wrote:
>
> Actually, as I mentioned in Wade's thread, the only drawback of JOGL's
> GLCanvas is its inferior performance compared to SWT's original canvas.

I hardly can see any reason why there is any performance drawback between
both native and heavyweight windowing bindings.
Maybe some GLCanvas/AWT managed code issue or Eclipse/SWT issue ?
Please provide a bit more information here.
Sorry that I have lost this thread.

~Sven

On Friday, January 28, 2011 00:55:03 Matt [via jogamp] wrote:
>
> Sven,
>
> I am actually using SWT, so I have no GLAutoDrawable instance, I am using
> SWT's GLCanvas.
>

Now it's all clear.

The SWT/JOGL binding is using an external GL context
and I am afraid this one is GL2 only.

To actually benefit and control the GL profile and more
like GLCapabilities (multisampling, ..) we would need a proper native SWT binding
utilizing the SWT's bound native windowing handle.

Another approach would be to gather the external GLContext's profile
and maybe more GLCapability flags.
This would allow to use an external GL3 context,
if the 'external party' (here SWT) is capable of creating it.
I doubt the latter.

Now all makes sense, sorry for that.
But there will be no remedy until this is resolved.

~Sven