Bug 1066 - Evaluate high-frequency usage of synchronizing glGetError(), e.g. GLBufferObjectTracker and GLBufferStateTracker
Summary: Evaluate high-frequency usage of synchronizing glGetError(), e.g. GLBufferObj...
Status: RESOLVED FIXED
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 2
Hardware: All all
: --- enhancement
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2014-09-12 21:31 CEST by Sven Gothel
Modified: 2015-01-27 15:03 CET (History)
2 users (show)

See Also:
Type: ---
SCM Refs:
7749f0567fb592ee4b3f698bd2424a5687b02f47 4d736527930511cabf2c6604aa831544da917198
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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!