JOGL2 performance versus JOGL1.1.1

So, I've compiled gluegen & JOGL2rc10 myself on a RHEL4 machine (with updates) and disabled all acceleration to get MESA to compile so I could compile JOGL.

I've installed the JOGL libraries on another machine that has full DRI running and my application is using double the CPU with clear flickering going on.
I don't getting flickering on a JOGL1.1.1 release and my conversion is purely to explicit GL2 interfaces instead of GL and to disable double-buffering (since we manage dirty rectangles ourselves).

I'm only installed the shared libraries so I would assume my application is sharing the GL+DRI shared libraries on the runtime machine and hasn't statically linked in the GL+noDRI libraries I compiled in order to compile JOGL.

So, I'm a little bamboozled right now.


FYI,  NVidia Quadro FX570 + drivers V295.59

Hi

I don't observe such problems with Nvidia Quadro FX 2000 (driver version 304.37 under Cent OS Linux 5.3, same results on RHEL 6) and Nvidia Quadro NVS 285 (driver version 295, Mageia Linux 2), the performance of JOGL 2.0 is extremely close to the one of JOGL 1.1.1a except sometimes when disabling the auto swap buffer mode but it is hardly reproducible.

On 09/27/2012 03:44 AM, gregirvine [via jogamp] wrote:
> So, I've compiled gluegen & JOGL2rc10 myself on a RHEL4 machine (with updates)
> and disabled all acceleration to get MESA to compile so I could compile JOGL.

great.

>
> I've installed the JOGL libraries on another machine that has full DRI running
> and my application is using double the CPU with clear flickering going on.
> I don't getting flickering on a JOGL1.1.1 release and my conversion is purely
> to explicit GL2 interfaces instead of GL and to disable double-buffering
> (since we manage dirty rectangles ourselves).

You compare JOGL1 w/ JOGL2 on same machine I assume ?

>
> I'm only installed the shared libraries so I would assume my application is
> sharing the GL+DRI shared libraries on the runtime machine and hasn't
> statically linked in the GL+noDRI libraries I compiled in order to compile JOGL.

JOGL1 and JOGL2 is linking against libGL.so.1 at runtime, yes.

What are we comparing here ?

Is your soft-mesa build in any way related here ?
Ofc .. soft-mesa cannot be compared w/ hw rendering.

Why don't you dump the following information
in your GLEventListener init method, just to be sure:

+++

    public void init(GLAutoDrawable drawable) {
        GL gl = drawable.getGL();
        System.err.println("Init on "+Thread.currentThread());
        System.err.println("Chosen GLCapabilities: " + drawable.getChosenGLCapabilities());
        System.err.println("INIT GL IS: " + gl.getClass().getName());
        System.err.println("GL_VENDOR: " + gl.glGetString(GL.GL_VENDOR));
        System.err.println("GL_RENDERER: " + gl.glGetString(GL.GL_RENDERER));
        System.err.println("GL_VERSION: " + gl.glGetString(GL.GL_VERSION));
        System.err.println("GL GLSL: "+gl.hasGLSL()+", has-compiler: "+gl.isFunctionAvailable("glCompileShader")+", version "+(gl.hasGLSL() ? gl.glGetString(GL2ES2.GL_SHADING_LANGUAGE_VERSION) : "none"));
        System.err.println("GL FBO: basic "+ gl.hasBasicFBOSupport()+", full "+gl.hasFullFBOSupport());
        System.err.println("GL Profile: "+gl.getGLProfile());
        System.err.println("GL:" + gl + ", " + gl.getContext().getGLVersion());

        .. your other GLEventListener init stuff ..

+++

If this doesn't give you a hint (GL version, caps, ..),
pls enable all debug flags and check whats happening. See Wiki/FAQ/Bugreport/..

>
> So, I'm a little bamboozled right now.

Me too .. there is absolutely nothing implemented which slows
down rendering.

Well, maybe the setting of the swap-interval (v-sync),
which is set to 1 by default, does something ?

~Sven

>
>
> FYI,  NVidia Quadro FX570 + drivers V295.59

Thanks Julien.
We have disabled auto-swap because we're not using double buffering.  This was the default behaviour in JOGL1 anyway as far as I can tell so we're not worse off.

>> I don't getting flickering on a JOGL1.1.1 release and my conversion is purely
>> to explicit GL2 interfaces instead of GL and to disable double-buffering
>> (since we manage dirty rectangles ourselves).

> You compare JOGL1 w/ JOGL2 on same machine I assume ?

Yep.

> What are we comparing here ?

I compiled my jogl2 libraries on a separate machine with a mesa library set I also compiled on that machine with DRI disabled.

The runtime machine has it's normal fully DRI capable libraries and hardware rending w/ Nvidia Quadro FX570.

> Ofc .. soft-mesa cannot be compared w/ hw rendering.

ofc.  8^)


> Why don't you dump the following information

gl.hasBasicFBOSupport() and full gl.hasFullFBOSupport() aren't present for some reason!

Other output for my JOGL2 version:
Chosen GLCapabilities: GLCaps[glx vid 0x28, fbc 0xc5: on-scr, rgba 0x8/8/8/0, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/0, one, mono  , hw, GLProfile[GL3bc/GL3bc.hw]]
INIT GL IS: jogamp.opengl.gl4.GL4bcImpl
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: Quadro FX 570/PCI/SSE2
GL_VERSION: 3.3.0 NVIDIA 270.18
GL GLSL: true, has-compiler: true, version 3.30 NVIDIA via Cg compiler
GL Profile: GLProfile[GL3bc/GL3bc.hw]
GL:jogamp.opengl.gl4.GL4bcImpl@164e5bf, 3.3 (Compatibility profile, arb, ES2 compatible, FBO, hardware) - 3.3.0 NVIDIA 270.18

>> So, I'm a little bamboozled right now.
> Me too .. there is absolutely nothing implemented which slows down rendering.
> Well, maybe the setting of the swap-interval (v-sync),
> which is set to 1 by default, does something ?


> FYI,  NVidia Quadro FX570 + drivers V295.59

I've tried different drivers - 304.xx and 270.19 (so I could use the nvidia-smi to assess GPU utilization, which is disabled in late rdriver versions).

On 09/28/2012 04:37 AM, gregirvine [via jogamp] wrote: Can you reproduce flickering w/ an existing unit test ?
If not, pls provide one.

In another reply of yours .. you mention single buffering and no swap,
well .. tearing is usually expected then (if not offscreen w/ manual compositing).

~Sven

Ok.  Time for me to get back to this flickering issue.

I've run a full performance assessment and found our application doesn't use more CPU with JOGL2 than JOGL1 which is great.

However, I have a clear flicker (every ~0.5s) when we force a full-screen clear and redraw (rather than a small dirty rectangle clear which is the normal when objects' data changes).  The flicker isn't always seen and it's very quick when it is but it's enough to be obvious (and annoying).  It only appears to occur on a full-screen clearRect+re-draw.

Unfortunately things are obviously commercial-in-confidence so I can't do videos or screenshots.

Details:
JOGL2rc10
Chosen GLCapabilities: GLCaps[glx vid 0x2a, fbc 0xcb: on-scr, rgba 0x8/8/8/0, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/0, one, mono  , hw, GLProfile[GL3bc/GL3bc.hw]]
GL Profile: GLProfile[GL3bc/GL3bc.hw]
GL:jogamp.opengl.gl4.GL4bcImpl@4f706d, 3.3 (Compatibility profile, arb, ES2 compatible, FBO, hardware) - 3.3.0 NVIDIA 275.09.07
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: Quadro FX 380/PCI/SSE2
GL_VERSION: 3.3.0 NVIDIA 275.09.07
GL GLSL: true, has-compiler: true, version 3.30 NVIDIA via Cg compiler


Capabilities setup:
// Force no double-buffering b/c the we use dirty-rectangles instead
GLCapabilities caps = new GLCapabilities(GLProfile.getDefault());
caps.setDoubleBuffered(false);
// no other specific settings

I must say I don't get any of these problems on any of my machines.

Configurations:

1. Mac Mini (2011) with Nvidia inside.

2. Windows 64 bit nvidia 9200 (8400 gs + 8600 gt).

3. Laptop sony vaio windows Vista 32 bit, intel GMA graphics card.

On 11/01/2012 04:32 AM, gregirvine [via jogamp] wrote:
> Ok.  Time for me to get back to this flickering issue.
>
> I've run a full performance assessment and found our application doesn't use
> more CPU with JOGL2 than JOGL1 which is great.

Good.

>
> However, I have a clear flicker (every ~0.5s) when we force a full-screen
> clear and redraw (rather than a small dirty rectangle clear which is the
> normal when objects' data changes).  
I really don't understand that statement, since usually we clear color buffer,
redraw and swap buffers.

So I assume you do something 'special' here - right, you do a single buffer
as you dumped that information below.
I only can assume some stuff related to SwapInterval and single buffer is the
issue at hand here .. that you get not only tearing but flickering.
Without a unit test I cannot say anything .. sorry (try set SwapInterval to 1
maybe).

Idea/Workaround: Use an FBO, do your special update mechanism in there
and dump it in a normal double buffered drawable.
This way it will also work on mobile (ES2 ..), where single buffer
configurations are rare.

> The flicker isn't always seen and it's
> very quick when it is but it's enough to be obvious (and annoying).  It only
> appears to occur on a full-screen clearRect+re-draw.
>
> Unfortunately things are obviously commercial-in-confidence so I can't do
> videos or screenshots.

And neither would help, but source code reproducing the bug.
RHEL4 ?

>
> Capabilities setup:
> // Force no double-buffering b/c the we use dirty-rectangles instead
> GLCapabilities caps = new GLCapabilities(GLProfile.getDefault());
> caps.setDoubleBuffered(false);
> // no other specific settings


~Sven

Can you put all of this information (yours, mine, Pixel.., etc)
in a bug report .. and we could cont. from there ?

~Sven

On 11/01/2012 03:48 PM, Sven Gothel wrote:
--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; fax : +49 (471) 4707741
Timezone CET: PST+9, EST+6, UTC+1

> So I assume you do something 'special' here - right, you do a single buffer

glScissor() so the glClear(COLOR_BUFFER_BIT) only clears inside our calculated dirty area and we redraw only the objects that intersect the dirty area.

We're only utilizing GL1 features like display lists and direct rendering - we've had no need to switch to VBO, vertex arrays, etc.

It's down-top command and control system, with no 3D texturing, heavy animation, etc. so there's no real issue with tearing.

Unfortunately sending code is far easier said than done.

My understanding with double buffering is the switched-to buffer contains the contents from when it was previously rendered (i.e is one full render cycle out of date) so to bring it full up-to-date it would have to be cleared and rendered in full, which we avoid doing for CPU load reasons (we have tight restrictions on CPU load as a part of our requirements).

Well, I've just discovered that it's Linux only.  I don't see the flickering on windows.  I've tried several versions of the driver (275, 270 expressly to be able to see the Gpu utilization (0%!), and the latest 304).

I do not see this flickering with our JOGL1 branch on the same hardware.

I've attached a brief video clip that shows the flickering.  This is a sub-section of the screen and the flicking - this visible band you can see - is across the screen with a strange polygonal shape and flashes across various parts of the screen most half second intervals.

OK, so my explicitly creating a GL2 profile instead of the default profile, the flickering has gone.
Quite strange really.

On 11/02/2012 05:16 AM, gregirvine [via jogamp] wrote:
> OK, so my explicitly creating a GL2 profile instead of the default profile,
> the flickering has gone.
> Quite strange really.

That is 'funny', indeed.
Your default profile probably gave you an GL4bc instance,
i.e. 4.2 w/ compatibility via ARB createContext - which should
should be 'compatible' so to speak :)

I would have thought that by now .. there are no regressions in the
GL driver regarding using a higher GL context version.

Great that you found it, maybe post it to Nvidia.

~Sven

Incredibly, this has come back again, at some stage after merging the original development in the trunk branch.

I'm totally stumped.  I've got the same NVIDIA driver version, the same GLCaps instantiation forcing GLProfile.GL2 as can be seen in the output below.  Everything else between the branches is the same... DAMNIT!

Chosen GLCapabilities: GLCaps[glx vid 0x28, fbc 0xc5: on-scr, rgba 0x8/8/8/0, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/0, one, mono  , hw, GLProfile[GL2/GL2.hw]]
GL_VENDOR  : NVIDIA Corporation
GL_VERSION : 3.3.0 NVIDIA 275.09.07
INIT GL IS : jogamp.opengl.gl4.GL4bcImpl
GL Profile : GLProfile[GL2/GL2.hw]
GL         :jogamp.opengl.gl4.GL4bcImpl@818737, 3.3 (Compatibility profile, arb, ES2 compatible, FBO, hardware) - 3.3.0 NVIDIA 275.09.07
GL_RENDERER: Quadro FX 380 LP/PCI/SSE2

On 01/22/2013 10:46 AM, gregirvine [via jogamp] wrote: Nothing wrong here.

You have requested a GL2 profile/context and you got:
  3.3 (Compatibility profile, arb, ES2 compatible, FBO, hardware) -
  3.3.0 NVIDIA 275.09.07

This one must be compatible w/ OpenGL 2.

Why do we return the maximum available ?
Because this aliasing (1) allows to
  - stop probing GL availability from high -> low
  - mix diff GLContext, or use the higher available features if available

We aliasing as follows:
  - Request: Any compat. profile -> Result: Highest avail. compat. profile
  - Request: Any core profile -> Result: Highest avail. core profile
hence we keep keep distinguishing core and compatibility since
implementation and semantics are different in many cases.
We don't want users to be surprised if testing e.g.
on mobile devices using ES2 or ES3.

+++

Well, if the GL '3.3.0 compatible' is not compatible w/ GL 2.1,
then there is a bug w/ your vendor.

However, you can disable the aliasing by defining the property:
  'jogl.debug.GLContext.NoProfileAliasing'

+++

(1) aliasing - When several different identifiers refer to the same object.
The term is very general and is used in many contexts.

Thanks for the response.  Unfortunately it still flickers, even with the -Djogl.debug.GLContext.NoProfileAliasing=true.
It's clearly impacted the GL version provided (was 3.3 is now 3.0).

INIT GL IS : jogamp.opengl.gl4.GL4bcImpl
GL         :jogamp.opengl.gl4.GL4bcImpl@16ac92e, 3.0 (Compatibility profile, arb, ES2 compatible, FBO, hardware) - 3.0.0 NVIDIA 275.09.07
Chosen GLCapabilities: GLCaps[glx vid 0x28, fbc 0xc5: on-scr, rgba 0x8/8/8/0, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/0, one, mono  , hw, GLProfile[GL2/GL2.hw]]
GL Profile : GLProfile[GL2/GL2.hw]
GL_VENDOR  : NVIDIA Corporation
GL_VERSION : 3.0.0 NVIDIA 275.09.07

On 01/22/2013 11:22 AM, gregirvine [via jogamp] wrote: I remember .. the flickering, which was gone once, now returned.

On 11/02/2012 05:16 AM, gregirvine [via jogamp] wrote:
> OK, so my explicitly creating a GL2 profile instead of the default profile,
> the flickering has gone.
> Quite strange really.

- GNU/Linux
- NVidia Quadro FX570
- Same NV driver ?
  - 275.09.07, 304.xx and 270.19, 270.18

Q0: Which JOGL version do you use ? Changed ?
Q1: Do you have VSync enabled properly ?
Q2: Do you use Animator (vsync) or FPSAnimator (timer based)
Q3: Whats are the durations of your render loops ? ~16ms -> 60Hz ?
Q4: AWT GLCanvas or NEWT GLWindow (or w/ NewtCanvasAWT) ?
Q5: Java Version ? Changed ?

~Sven

> I remember .. the flickering, which was gone once, now returned.
> OK, so my explicitly creating a GL2 profile instead of the default profile,
> the flickering has gone.
> Quite strange really.

Yep!

> - GNU/Linux

Yep, still RHEL4 (yes, I know.  it took me a LONG time to get it to compile, as per my other forum threads)

> - NVidia Quadro FX570

Quadro FX380 LP

> - Same NV driver ?
>  - 275.09.07, 304.xx and 270.19, 270.18

Yep, I put the 275.09.07 driver on after checking my previous posts.

> Q0: Which JOGL version do you use ? Changed ?

2.0rc10 (same as before)

> Q1: Do you have VSync enabled properly ?

Not sure.  I didn't change it from the default in either case.

> Q2: Do you use Animator (vsync) or FPSAnimator (timer based)

FPS Animator set to 24fps but we internally reduce it to ~10fps for load reduction except during interactions requiring smoother rendering

> Q3: Whats are the durations of your render loops ? ~16ms -> 60Hz ?

off the top of my head i don't remember, but i think it was something like 3ms.

> Q4: AWT GLCanvas or NEWT GLWindow (or w/ NewtCanvasAWT) ?

AWT GLCanvas (same as before)

> Q5: Java Version ? Changed ?

6.0.31, same as before.

On 01/22/2013 11:41 AM, gregirvine [via jogamp] wrote: Assuming flickering is not tearing, vsync should not be the issue at hand.

>
>> Q4: AWT GLCanvas or NEWT GLWindow (or w/ NewtCanvasAWT) ?
>
> AWT GLCanvas (same as before)
>
>> Q5: Java Version ? Changed ?
>
> 6.0.31, same as before.

So what has changed ?

Your application ? You mention
'merging the original development in the trunk branch'.

If you revert to your last known working software - it still works ?

+++

Flickering could be perceived if you render e.g. a black/white frame
in between .. a flash will happen
 -  could be background clear (not by GLCanvas though)
 - VBO not enabled
 - PMV off ..

Disregard the No-Alias property.

Try to run w/ property jogl.debug.DebugGL,
maybe some GL errors are reported.

Try to run w/ property jogl.debug.TraceGL,
maybe you see a missing VBO toggle state.

~Sven

The performance is excellent. I have testet it with Nvidea from GTX 480 to GTX 590.
With an average of 7000 polygons i got framerates with vbo's from 2400 - 2800 FPS,
if  setSwapInterval(0) is set.
Also a Phong Shader with cloud textures a set.