Bug 1066

Summary:	Evaluate high-frequency usage of synchronizing glGetError(), e.g. GLBufferObjectTracker and GLBufferStateTracker
Product:	[JogAmp] Jogl	Reporter:	Sven Gothel <sgothel>
Component:	core	Assignee:	Sven Gothel <sgothel>
Status:	RESOLVED FIXED
Severity:	enhancement	CC:	iiiaqd, sgothel
Priority:	---
Version:	2.3.0
Hardware:	All
OS:	all
Type:	---	SCM Refs:	7749f0567fb592ee4b3f698bd2424a5687b02f47 4d736527930511cabf2c6604aa831544da917198
Workaround:	---

Description Sven Gothel 2014-09-12 21:31:41 CEST

<http://forum.jogamp.org/Why-glGetError-calls-tp4033139.html>

+++

On 09/12/2014 04:10 PM, aqd [via jogamp] wrote:> Hello jogl devs! Can someone explain to me why all the glGetError() calls in
> GLBufferObjectTracker and GLBufferStateTracker? Aren't glGetError() calls
> supposed to be expensive? And what's the point of checking unrecoverable error
> when buffers are created? Are they merely made for backward-compatibility (I
> saw comments about mesa, is it still alive?)
> 
> I turned it off in my own project and performance of drawing WorldWind
> annotations seems improving, jumped from 80+FPS to 130+FPS with several dozens
> of annotation labels.

+++

Interesting point, i.e. performance vs error-checking.
The latter uses glGetError() and indeed forces the driver to synchronize.

One valid usage of error-checking are initialization sequences, 
e.g. as used in FBObject.
Those are required for functionality and shall not be expected 
in 'animating display' calls, i.e. high frequency usage.

If GLBufferObjectTracker and GLBufferStateTracker glGetError() usage
is done in 'high frequent' methods .. we shall evaluate.

Further we shall evaluate other places.

Comment 1 Sven Gothel 2014-09-21 01:32:28 CEST

7749f0567fb592ee4b3f698bd2424a5687b02f47

Bug 1066: Reduce glGetError() in FBObject / GLFBODrawableImpl

- GLFBODrawableImpl
  - cache getMaxRenderbufferSamples() result from initialize call,
    method checks glGetError()

- FBObject
  - init(..): Remove one redundant checkPreGLError()

  - Allow reset(..) / modify-attachment-operations w/o glGetError():
    - Only check error if DEBUG || GLContext.DEBUG_GL:
      - RenderAttachment.initialize()
      - TexureAttachment.initialize()
      - syncSamplingSink(gl)

+++

4d736527930511cabf2c6604aa831544da917198

Bug 1066: Reduce glGetError() in GLDrawableHelper.reshape(.., setViewport==true)

Only check error if DEBUG || GLContext.DEBUG_GL in GLDrawableHelper.reshape(.., setViewport==true)

+++

Comment 2 Sven Gothel 2014-09-21 01:37:07 CEST

@iiiaqd (Any change to give your real name?): 

Can you please provide a 'hit list' / hotspots
of glGetError() within GLBufferObjectTracker and GLBufferStateTracker.

I currently walk through its utilization..

GLBufferStateTracker.getBoundBufferObject() only use glGetError() 
in it's slow-path, i.e. if the 'pname' is not mapped.
Is the slow path being hit often ?

GLBufferObjectTracker.createBufferStorage(..) 
uses it to ensure the operation was successful, 
before mapping the native memory!
I dunno whether we shall allow skipping this check.

Would be nice if you can produce some performance stats.

Best if you could produce a unit test showing the result,
so we can find the hotspots.
The fps value shall allows us validate changes.

Comment 3 Sven Gothel 2014-09-21 01:55:21 CEST

(In reply to comment #2)
> 
> GLBufferObjectTracker.createBufferStorage(..) 
> uses it to ensure the operation was successful, 

i.e. whether the buffer storage was created (not mapped).
It seems no other method allows to validate this.
We have to analyze this, in case this is a hotspot,
which I doubt.

GLBufferObjectTracker.mapBuffer*(..) is implemented
a bit smarter, i.e. simply passes the NULL value
in case of an error - w/o glGetError() checking.

Comment 4 Sven Gothel 2014-10-09 06:47:36 CEST

I leave this bug report open for a while, 
even thought I would like to have a response from the 
anonymous reporter, so we could continue working on the issue.

Thank you!

Comment 5 Sven Gothel 2015-01-27 15:03:52 CET

No further response for 3 month, closing this bug report.

If anybody finds more GL sync issues which we shall remove, 
pls re-open it and comment on it! thx!