What profile to choose?

So I'm venturing into JOGL2 from JOGL 1.1.1, but I'm a little confused by the Profile thing.  I've read Michael Bien's blog post, but I'm still not sure what fits.  My main desire with moving to JOGL2 is performance and staying on a current framework.  I can say that my desktop users are running at least OpenGL 2.1 - my minimum requirement as I use point sprites.  I need to maintain that minimum requirement as some of these computers are several years old and unlikely to be updated.  Since I'm going to have to recode it, I'd like to make it as advanced as possible, while still making sure everyone can use it.  I have no plans to introduce multiple profiles based on the users version - too much work for what I'm doing.  I also have no plans to support mobile, so any compatibility with that would be a bonus but it's not required and I don't want to limit my existing functionality.

So what profile to use...
* GL2
* GL3bc
* GL4bc
* GL2ES1
* GL2ES2
* GL2GL3
or something else?

Thanks for any guidance you can provide,
Jeff

On Saturday, December 10, 2011 04:18:37 PM Jeffg [via jogamp] wrote:
>
> So I'm venturing into JOGL2 from JOGL 1.1.1, but I'm a little confused by the
> Profile thing.  I've read Michael Bien's
> http://michael-bien.com/mbien/entry/jogl_2_opengl_profiles_explained blog

Well .. maybe you like to try the 'original' document:
  http://jogamp.org/jogl/doc/Overview-OpenGL-Evolution-And-JOGL.html
(He reuses the UML diagram I created)

It all boils down to fixed-function or programmable pipeline,
pls read the doc linked above.

IE. if you desire to run your stuff on mobile and desktop
then you might like to choose:
  GL2ES1 for GL2 + ES1 common profile fixed-function pipeline
  GL2ES2 for GL2 + ES2 common profile programmable pipeline

Then you can use specifics in your render methods if you desire
by querying the profile, ie. gl.isGL* .. or by quering extensions.
        gl.isExtensionAvailable(String glExtensionName)
        gl.isGL3()

This is how your create a GL2ES2 compatible profile/caps:

        if(!GLProfile.isAvailable(GLProfile.GL2ES2)) {
            System.out.println("GLProfile GL2ES2 n/a");
            return;
        }
        GLProfile glp = GLProfile.getGL2ES2();
        GLCapabilities caps = new GLCapabilities(glp);
        GLWindow glWindow = GLWindow.create(caps);
        Assert.assertNotNull(glWindow);
        glWindow.setTitle("TestGLProfile01NEWT");

        glWindow.addGLEventListener(new DumpGLInfo());

        glWindow.setSize(128, 128);
        glWindow.setVisible(true);

        glWindow.display();
        Thread.sleep(100);
        glWindow.destroy();

GLProfile will always attempt to use the highest available profile
compatible w/ the desired one, ie GL2ES2.

~Sven

On Saturday, December 10, 2011 04:54:01 PM Sven Gothel wrote:
Further readings:
  http://jogamp.org/doc/siggraph2010/jogamp-siggraph2010.pdf
  http://jogamp.org/doc/siggraph2011/jogamp-siggraph2011.pdf

~Sven

Thanks for the info - I've read through the links you posted.  Here is some of my confusion - I use shaders, so I know I utilize the programmable pipeline, but I'm less clear on what calls represent a fixed pipeline call.  For example, let's say I create a display list that creates a quad, no shader called, is that using the fixed pipeline?

Also, I guess I'm having trouble understanding if compatibility is for the API or OpenGL itself.  For example, does using GL3 or GL4 make you're application incompatible with someone running OpenGL 2.1 if you don't make calls that 2.1 doesn't support?  If so, does using GL4bc change that, or does it just allow your API to use commands that are part of the fixed pipeline (again, which I don't quite get).  Why would you use GL3bc over GL4bc, if GL4bc is backward compatible?  I think I understand the mobile vs desktop, as the mobile profile would probably prevent you from calling things that are not available on mobile devices.  Is that the same with GL2 vs GL3.. GL2 just prevents you from making calls to commands only available on OpenGL 3.1?  If you used GL3, but didn't make calls above a GL2 level, would you gain anything by using a higher GL level.. so if the user had installed OpenGL 3.1, would using GL3 with GL2 calls improve performance or anything?

Sorry for all the questions - I appreciate the assistance.
- Jeff

On Saturday, December 10, 2011 06:05:01 PM Jeffg [via jogamp] wrote:
>
> Thanks for the info - I've read through the links you posted.  Here is some
> of my confusion - I use shaders, so I know I utilize the programmable
> pipeline, but I'm less clear on what calls represent a fixed pipeline call.
> For example, let's say I create a display list that creates a quad, no
> shader called, is that using the fixed pipeline?

Display lists are deprecated in core profiles for OpenGL 3 and 4,
hence GL3 and GL4 doesn't have them in (but GL3bc and GL4bc).
First of all, GLBase, GL, GL2ES2, GL2GL3, GL2, GL3, GLES2, .. are all interfaces.
The only implementations are: GL4bcImpl for desktop and GLES1Impl/GLES2Impl for mobile.

Since the interfaces all derive from each other according to the GL profile spec,
you can safely cast your instance to any compatible profile's interface:

  GL gl;
  if(gl.isGL3()) {
    GL3 gl3 = gl.getGL3();
    // do GL3 specifics ..
  }


Ususally you don't do this:

(E1)
   GLCapabilities caps = new GLCapabilities(GLProfile.get(GLProfile.GL3));
   GLWindow glWindow = GLWindow.create(caps);
   ...

but this:

(E2)

   GLCapabilities caps = new GLCapabilities(GLProfile.getGL2ES2());
   GLWindow glWindow = GLWindow.create(caps);
   ...

or this:

(E3)

   GLCapabilities caps = new GLCapabilities(GLProfile.getDefault());
   GLWindow glWindow = GLWindow.create(caps);
   ...

Both, E2 and E3 will result with the highest GL context possible compatible
with the requested one - here the 1st available:
   GL2ES2: GL4bc, GL4, GL3bc, GL3, GL2 or ES2
   default: GL4bc, GL3bc, GL2, GL4, GL3, GL2GL3, GLES2, GL2ES2, GLES1, GL2ES1

   http://jogamp.org/git/?p=jogl.git;a=blob;f=src/jogl/classes/javax/media/opengl/GLProfile.java;hb=HEAD#l1580

E1 is not desired, since you don't know what is available on your clients platform
so you might want to query it (see last post and Siggraph 2010 presentation p9 or so ..).

With E2 and E3 you are most flexible. Sure - if you require some sort of features
and they are not available you can query that upfront and make a 'nice' exit.

>
> Sorry for all the questions - I appreciate the assistance.

Hope this helps a bit.

Maybe some additional browsing / reading of the actual GL specs may help, eg:

http://www.opengl.org/registry/doc/glspec42.core.20110808.pdf
  - Appendix E, specifically E.2

Of course, you can also check the different GL interfaces
which clearly show whats available in the common subsets (GL2GLES1, GL2ES2, GL2GL3)
and their 'final' interfaces (GL2, GL3, .., GLES2).

~Sven


> - Jeff

On Saturday, December 10, 2011 09:40:02 PM Sven Gothel wrote:
(E4/E5)
    GLCapabilities caps = new GLCapabilities(GLProfile.getMaxProgrammable());
    GLWindow glWindow = GLWindow.create(caps);
    ...

    GLCapabilities caps = new GLCapabilities(GLProfile.getMaxFixedFunc());
    GLWindow glWindow = GLWindow.create(caps);
    ...

E4/E5 limit the use on a specific 'branch' of GL profile,
ie programmable or fixed-function.

In regards to fixed function pipeline, I would always avoid immediate mode
and display lists, since they are not even supported on mobile devices ES1 profile.
If you properly use VBOs instead of the above, your fixed function code would most likely
work on GL2ES1 and hence ES1 mobile devices.
Ofc .. today the most desired way to impl. 3D is programmable pipeline due to todays hw GPU design.