<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.
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) +++
@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.
(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.
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!
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!