unusable profile selected with GL2ES2 capabilities - a bug or a ..feature?

Hi,
I'm developing an OpenGL ES2.0 application with jogl, primarily on desktop platforms with possible android platform expansion in the future.

With relatively newer GPUs when I try to get a profile by specifying GL2ES2 as capability, the GL4bc profile is selected. On Mac OS X / Intel graphics as well as Linux / AMD graphics, this profile would fail to compile the ES shaders with:
a) complaining about a missing #version directive, regarding which AFAIK it is not necessary and
b) complaining about GL3 forward compatible context.
Please have a look at the sample output regarding the error.

The simplest solution is to ask for a GL3bc or even a GL2 profile, which actually compiles the shaders and performs perfectly.

Why is the GL4bc profile returned as a viable profile when specifying GL2ES2 as capability when this is clearly not the case?

Looking forward to any explanation.
Regards


-----sample output of the error on linux / AMD graphics platform -------------
Chosen GLCapabilities: GLCaps[glx vid 0xc8, fbc 0xc8: rgba 8/8/8/8, trans-rgba 0xff/ff/ff/ff, accum-rgba 0/0/0/0, dp/st/ms 24/0/0, dbl, mono  , hw, GLProfile[GL2ES2/GL4.hw], on-scr[.]]
INIT GL IS: jogamp.opengl.gl4.GL4bcImpl
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: AMD Radeon HD 7700 Series
GL_VERSION: 4.2.12217 Core Profile Context 12.104
Error compiling the vertex shader: Vertex shader failed to compile with the following errors:
ERROR: error(#272) Implicit version number 110 not supported by GL3 forward compatible context
ERROR: error(#273) 1 compilation errors.  No code generated

eimaiosatanas wrote

Hi,
I'm developing an OpenGL ES2.0 application with jogl, primarily on desktop platforms with possible android platform expansion in the future.

With relatively newer GPUs when I try to get a profile by specifying GL2ES2 as capability, the GL4bc profile is selected. On Mac OS X / Intel graphics as well as Linux / AMD graphics, this profile would fail to compile the ES shaders with:
a) complaining about a missing #version directive, regarding which AFAIK it is not necessary and
b) complaining about GL3 forward compatible context.
Please have a look at the sample output regarding the error.

The simplest solution is to ask for a GL3bc or even a GL2 profile, which actually compiles the shaders and performs perfectly.

Why is the GL4bc profile returned as a viable profile when specifying GL2ES2 as capability when this is clearly not the case?

Looking forward to any explanation.
Regards


-----sample output of the error on linux / AMD graphics platform -------------
Chosen GLCapabilities: GLCaps[glx vid 0xc8, fbc 0xc8: rgba 8/8/8/8, trans-rgba 0xff/ff/ff/ff, accum-rgba 0/0/0/0, dp/st/ms 24/0/0, dbl, mono  , hw, GLProfile[GL2ES2/GL4.hw], on-scr[.]]
INIT GL IS: jogamp.opengl.gl4.GL4bcImpl
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: AMD Radeon HD 7700 Series
GL_VERSION: 4.2.12217 Core Profile Context 12.104
Error compiling the vertex shader: Vertex shader failed to compile with the following errors:
ERROR: error(#272) Implicit version number 110 not supported by GL3 forward compatible context
ERROR: error(#273) 1 compilation errors.  No code generated

If you look close enough GLProfile[GL2ES2/GL4.hw] context is selected, that is GL4 without backward compatibility.
We are discussing this inside the following bug:
https://jogamp.org/bugzilla/show_bug.cgi?id=821

According to the JogAmp JOGL spec the current JOGL implementation is correct:
"GL2ES2 The intersection of the desktop GL3, GL2 and embedded ES2 profile"
https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GL2ES2.html
Its the intersection of GL3 (core) that makes GL2ES2 return a non backward compatible context and require you to use VBO for best compatibility on both desktop and mobile devices.

You can add a header to your vertex shader in order to make it compile on more drivers:

#if __VERSION__ >= 130
  #define attribute in
  #define varying out
#endif

#ifdef GL_ES
  precision mediump float;
  precision mediump sampler2D;
  precision mediump int;
#endif


and similar for the fragment shader:

#if __VERSION__ >= 130
  #define varying in
  out vec4 mgl_FragColor;
  #define texture2D texture
#else
  #define mgl_FragColor gl_FragColor
#endif

#ifdef GL_ES
  precision mediump float;
  precision mediump sampler2D;
  precision mediump int;
#endif

Xerxes, thanks for the prompt reply!

100% correct, it's not the GL4bc profile, but the GL4 profile.

And again, 100% correct when you said in the other thread:
"The naming GL2ES2 may be confusing for new users, like myself, who expect it to only include the intersection of GL2 and ES2".

Thanks for the pointers for modifying the shaders. For the time being, I'll stick with asking a GL3bc/GL2 profile, until something breaks.

The thing that bugged me the most though is that I tried to get a pure GLES2 profile, which is not supported natively by the desktop vga and the call fails with an exception. Wouldn't it be preferable instead of failing with an exception to return a profile with backwards compatibility (and GL ES 2.0 support), such as GL4bc/GL3bc or even GL2?

I'd love to hear any insights that you and the devs might have regarding this one.

Cheers!

eimaiosatanas wrote

The thing that bugged me the most though is that I tried to get a pure GLES2 profile, which is not supported natively by the desktop vga and the call fails with an exception. Wouldn't it be preferable instead of failing with an exception to return a profile with backwards compatibility (and GL ES 2.0 support), such as GL4bc/GL3bc or even GL2?

No it is a bad idea in my humble opinion because you can still catch this exception and you can know which profiles are supported anyway before trying to use a particular one, I do that in Ardor3D.

gouessej wrote

No it is a bad idea in my humble opinion because you can still catch this exception and you can know which profiles are supported anyway before trying to use a particular one, I do that in Ardor3D.

Ah, so it is more like a "feature" then :) . Ok got it. One way is to programmatically handle this case, starting from GLES2, and failing that ask for GL4bc, GL3bc and lastly GL2 profiles in that order. That should get me a usable profile every time, at least in theory.

In the mean time, I'd better take a look at the source code for Ardor3D then, see how it handles the GL profiles.

Thank you for your replies kind sirs, they have been most elucidating!

eimaiosatanas wrote

GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: AMD Radeon HD 7700 Series
GL_VERSION: 4.2.12217 Core Profile Context 12.104
Error compiling the vertex shader: Vertex shader failed to compile with the following errors:
ERROR: error(#272) Implicit version number 110 not supported by GL3 forward compatible context
ERROR: error(#273) 1 compilation errors.  No code generated

This particular error can only be avoided by adding a version line
#version 130
// GLSL 1.3 is the lowest version of GLSL supported by OpenGL 3 core GLSL spec
at the top of the vertex and fragment shader when using a GL3 or GL4 context.
It looks like AMD GPU drivers enforce the opengl spec that require the version to be explicitly set.

or... use a backward compatible context.

On 08/30/2013 06:49 PM, Xerxes Rånby [via jogamp] wrote:
.. allow me to advertise our default shader customizations:
 
<http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/RedSquareES2.java;h=1ba4d126fd3789a735a316c28b959b18a28e1094;hb=HEAD#l80>

  final ShaderCode vp0 = ShaderCode.create(gl, GL2ES2.GL_VERTEX_SHADER, this.getClass(), "shader",
          "shader/bin", "RedSquareShader", true);
  final ShaderCode fp0 = ShaderCode.create(gl, GL2ES2.GL_FRAGMENT_SHADER, this.getClass(), "shader",
          "shader/bin", "RedSquareShader", true);
  vp0.defaultShaderCustomization(gl, true, true);
  fp0.defaultShaderCustomization(gl, true, true);
  final ShaderProgram sp0 = new ShaderProgram();
  sp0.add(gl, vp0, System.err);
  sp0.add(gl, fp0, System.err);

Note: You can check our other demos which all 'edit' the shader code
in runtime to match the running GL context.
Some even inject specific texture lookup functions etc (GLMediaPlayer, ..)
using the ShaderCode class.

+++

'defaultShaderCustomization(..)' of class ShaderCode
adds the accurate GLSL version and the default precision
is so requested.

The GLSL version is queried via: GLContext's getGLSLVersionString()'.

+++

Further more .. GLContext provides a method 'isGLcore()',
which allows you to query whether this context is core only
and may be restricted by VBO only usage .. etc.

  /**
   * Indicates whether this GLContext uses a GL core profile. <p>Includes [ GL4, GL3, GLES3, GL2ES2 ].</p>
   */
  public final boolean isGLcore() {
      return ( 0 != ( ctxOptions & CTX_PROFILE_ES ) && ctxVersion.getMajor() >= 2 ) ||
             ( 0 != ( ctxOptions & CTX_IS_ARB_CREATED ) &&
               0 != ( ctxOptions & CTX_PROFILE_CORE ) &&
               ctxVersion.compareTo(Version310) >= 0
             ) ;
  }


~Sven