New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regressions wrt GLES2 support between b4 and b7 #3976

Closed
gohai opened this Issue Oct 9, 2015 · 16 comments

Comments

Projects
None yet
3 participants
@gohai
Contributor

gohai commented Oct 9, 2015

Testing beta 7 on true GLES 2 part, I am seeing runtime exceptions in more example sketches that I haven't on beta 4. (Note: this is with a newer release of the Raspberry Pi distribution - which might or might not have touched the driver or the GPU firmware - and a more recent JOGL as well)

At least the following example now throw an exception about glReadBuffer() not being present (which is expected on GLES2) - they used to work before:

Basics/Form/Primitives3D
Demos/Graphics/LowLevelGLVboInterleaved
Demos/Graphics/LowLevelGLVboSeparate
Demos/Tests/NoBackgroundTest
Demos/Tests/SpecsTest
Topics/Shaders/Monjori
Topics/Shaders/Nebula

@JakubValtar @codeanticode Any ideas?

Will try 3.0 next.

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Oct 9, 2015

Contributor

Sometimes I do get a stack trace, it's always the same - as seen here coming from Demos/Tests/SpecsTest:

java.lang.RuntimeException: GL function glReadBuffer() is not available on this hardware (or driver) Read http://wiki.processing.org/w/OpenGL_Issues for help.
at processing.opengl.PJOGL.readBuffer(PJOGL.java:1898)
at processing.opengl.PJOGL.initFBOLayer(PJOGL.java:298)
at processing.opengl.PGL.createFBOLayer(PGL.java:952)
at processing.opengl.PGL.beginRender(PGL.java:721)
at processing.opengl.PGraphicsOpenGL.beginOnscreenDraw(PGraphicsOpenGL.java:6571)
at processing.opengl.PGraphicsOpenGL.beginDraw(PGraphicsOpenGL.java:1550)
at processing.core.PApplet.handleDraw(PApplet.java:2360)
at processing.opengl.PSurfaceJOGL$DrawListener.display(PSurfaceJOGL.java:761)
at jogamp.opengl.GLDrawableHelper.displayImpl(GLDrawableHelper.java:692)
at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:674)
at jogamp.opengl.GLAutoDrawableBase$2.run(GLAutoDrawableBase.java:443)
at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1291)
at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1145)
at com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:759)
at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:81)
at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:452)
at com.jogamp.opengl.util.FPSAnimator$MainTask.run(FPSAnimator.java:178)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Contributor

gohai commented Oct 9, 2015

Sometimes I do get a stack trace, it's always the same - as seen here coming from Demos/Tests/SpecsTest:

java.lang.RuntimeException: GL function glReadBuffer() is not available on this hardware (or driver) Read http://wiki.processing.org/w/OpenGL_Issues for help.
at processing.opengl.PJOGL.readBuffer(PJOGL.java:1898)
at processing.opengl.PJOGL.initFBOLayer(PJOGL.java:298)
at processing.opengl.PGL.createFBOLayer(PGL.java:952)
at processing.opengl.PGL.beginRender(PGL.java:721)
at processing.opengl.PGraphicsOpenGL.beginOnscreenDraw(PGraphicsOpenGL.java:6571)
at processing.opengl.PGraphicsOpenGL.beginDraw(PGraphicsOpenGL.java:1550)
at processing.core.PApplet.handleDraw(PApplet.java:2360)
at processing.opengl.PSurfaceJOGL$DrawListener.display(PSurfaceJOGL.java:761)
at jogamp.opengl.GLDrawableHelper.displayImpl(GLDrawableHelper.java:692)
at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:674)
at jogamp.opengl.GLAutoDrawableBase$2.run(GLAutoDrawableBase.java:443)
at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1291)
at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1145)
at com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:759)
at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:81)
at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:452)
at com.jogamp.opengl.util.FPSAnimator$MainTask.run(FPSAnimator.java:178)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)

@codeanticode codeanticode added the opengl label Oct 10, 2015

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Oct 10, 2015

Member

we could remove the exception from PJOGL.readBuffer() and PJOGL.drawBuffer() since are common operations, @JakubValtar what do you think?

Member

codeanticode commented Oct 10, 2015

we could remove the exception from PJOGL.readBuffer() and PJOGL.drawBuffer() since are common operations, @JakubValtar what do you think?

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Oct 10, 2015

Contributor

@codeanticode This seems to be caused by forced FBO. Does Pi support FBOs?

I think solution should be not calling the function if it's not supported, not hiding the exception and leaving it broken.

Contributor

JakubValtar commented Oct 10, 2015

@codeanticode This seems to be caused by forced FBO. Does Pi support FBOs?

I think solution should be not calling the function if it's not supported, not hiding the exception and leaving it broken.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Oct 10, 2015

Member

I think RPi supports FBOs. What its version of GL does not support are the read/drawBuffer functions, which are used in several places in the renderer's code, such as beginPixelsOp, endPixelsOp, initFBOLayer, restoreGL. Since you cannot change the default draw and read buffers in the RPi anyways, I guess that doing nothing when the user calls these functions should not have any effect.

Member

codeanticode commented Oct 10, 2015

I think RPi supports FBOs. What its version of GL does not support are the read/drawBuffer functions, which are used in several places in the renderer's code, such as beginPixelsOp, endPixelsOp, initFBOLayer, restoreGL. Since you cannot change the default draw and read buffers in the RPi anyways, I guess that doing nothing when the user calls these functions should not have any effect.

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Oct 10, 2015

Contributor

Why do we call these functions again if they have no effect? To reset if
user changed it directly through PGL?

If that's the case:
It's supported everywhere except ES2. I'd put there hasReadDrawBuffer() in
the same fashion as hasSynchronization(), query it on startup into boolean,
then use the boolean to check if we should call readBuffer() and
drawBuffer() each time.

I don't think we should have silently failing methods, you can't rely on
the outcome once you really need it to work.

On Sat, 10 Oct 2015, 13:17 codeanticode notifications@github.com wrote:

I think RPi supports FBOs. What its version of GL does not support are the
read/drawBuffer functions, which are used in several places in the
renderer's code, such as beginPixelsOp
https://github.com/processing/processing/blob/master/core/src/processing/opengl/PGraphicsOpenGL.java#L1760,
endPixelsOp
https://github.com/processing/processing/blob/master/core/src/processing/opengl/PGraphicsOpenGL.java#L1777,
initFBOLayer
https://github.com/processing/processing/blob/master/core/src/processing/opengl/PJOGL.java#L309,
restoreGL
https://github.com/processing/processing/blob/master/core/src/processing/opengl/PGraphicsOpenGL.java#L1685.
Since you cannot change the default draw and read buffers in the RPi
anyways, I guess that doing nothing when the user calls these functions
should not have any effect.


Reply to this email directly or view it on GitHub
#3976 (comment)
.

Contributor

JakubValtar commented Oct 10, 2015

Why do we call these functions again if they have no effect? To reset if
user changed it directly through PGL?

If that's the case:
It's supported everywhere except ES2. I'd put there hasReadDrawBuffer() in
the same fashion as hasSynchronization(), query it on startup into boolean,
then use the boolean to check if we should call readBuffer() and
drawBuffer() each time.

I don't think we should have silently failing methods, you can't rely on
the outcome once you really need it to work.

On Sat, 10 Oct 2015, 13:17 codeanticode notifications@github.com wrote:

I think RPi supports FBOs. What its version of GL does not support are the
read/drawBuffer functions, which are used in several places in the
renderer's code, such as beginPixelsOp
https://github.com/processing/processing/blob/master/core/src/processing/opengl/PGraphicsOpenGL.java#L1760,
endPixelsOp
https://github.com/processing/processing/blob/master/core/src/processing/opengl/PGraphicsOpenGL.java#L1777,
initFBOLayer
https://github.com/processing/processing/blob/master/core/src/processing/opengl/PJOGL.java#L309,
restoreGL
https://github.com/processing/processing/blob/master/core/src/processing/opengl/PGraphicsOpenGL.java#L1685.
Since you cannot change the default draw and read buffers in the RPi
anyways, I guess that doing nothing when the user calls these functions
should not have any effect.


Reply to this email directly or view it on GitHub
#3976 (comment)
.

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Oct 10, 2015

Contributor

Could glReadPixels somehow be used in lieu? This one exists on GLES2. (I really don't know anything about graphics programming, I should point out.) Thanks for looking into this!

Contributor

gohai commented Oct 10, 2015

Could glReadPixels somehow be used in lieu? This one exists on GLES2. (I really don't know anything about graphics programming, I should point out.) Thanks for looking into this!

@gohai gohai added this to the 3.0.1 milestone Oct 11, 2015

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Oct 11, 2015

Contributor

This be great to have for people giving Processing on ARM a try - please remove milestone if you think otherwise!

Contributor

gohai commented Oct 11, 2015

This be great to have for people giving Processing on ARM a try - please remove milestone if you think otherwise!

@codeanticode codeanticode self-assigned this Oct 12, 2015

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Oct 12, 2015

Contributor

Super. I'll go test this in a couple of minutes!

Contributor

gohai commented Oct 12, 2015

Super. I'll go test this in a couple of minutes!

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Oct 12, 2015

Contributor

Looks good @codeanticode :)

Contributor

JakubValtar commented Oct 12, 2015

Looks good @codeanticode :)

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Oct 12, 2015

Contributor

Now we trip over glBlitFramebuffer on GLES2.

at processing.opengl.PJOGL.blitFramebuffer(PJOGL.java:1876)
at processing.opengl.PJOGL.initFBOLayer(PJOGL.java:310)
at processing.opengl.PGL.createFBOLayer(PGL.java:952)
at processing.opengl.PGL.beginRender(PGL.java:721)
at processing.opengl.PGraphicsOpenGL.beginOnscreenDraw(PGraphicsOpenGL.java:6573)
Contributor

gohai commented Oct 12, 2015

Now we trip over glBlitFramebuffer on GLES2.

at processing.opengl.PJOGL.blitFramebuffer(PJOGL.java:1876)
at processing.opengl.PJOGL.initFBOLayer(PJOGL.java:310)
at processing.opengl.PGL.createFBOLayer(PGL.java:952)
at processing.opengl.PGL.beginRender(PGL.java:721)
at processing.opengl.PGraphicsOpenGL.beginOnscreenDraw(PGraphicsOpenGL.java:6573)

@gohai gohai changed the title from Regressions wrt glReadBuffer() between b4 and b7 to Regressions wrt GLES2 support between b4 and b7 Oct 12, 2015

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode
Member

codeanticode commented Oct 12, 2015

try this 9dee44e

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Oct 12, 2015

Contributor

Now getting a GL error 0x500. First frame renders fine, but it falls apart on the second.

With JOGL debugging turned on:

com.jogamp.opengl.GLException: Thread[main-FPSAWTAnimator#00-Timer0,5,main] glGetError() returned the following error codes after a call to glGetIntegerv(<int> 0x8D57, <java.nio.IntBuffer> java.nio.DirectIntBufferU[pos=0 lim=2 cap=2]): GL_INVALID_ENUM ( 1280 0x500), 
at com.jogamp.opengl.DebugGLES3.writeGLError(DebugGLES3.java:8241)
at com.jogamp.opengl.DebugGLES3.glGetIntegerv(DebugGLES3.java:3476)
at processing.opengl.PJOGL.getIntegerv(PJOGL.java:1057)
at processing.opengl.PGL.maxSamples(PGL.java:2211)
at processing.opengl.PGL.createFBOLayer(PGL.java:881)
at processing.opengl.PGL.beginRender(PGL.java:721)
at processing.opengl.PGraphicsOpenGL.beginOnscreenDraw(PGraphicsOpenGL.java:6573)
at processing.opengl.PGraphicsOpenGL.beginDraw(PGraphicsOpenGL.java:1552)
Contributor

gohai commented Oct 12, 2015

Now getting a GL error 0x500. First frame renders fine, but it falls apart on the second.

With JOGL debugging turned on:

com.jogamp.opengl.GLException: Thread[main-FPSAWTAnimator#00-Timer0,5,main] glGetError() returned the following error codes after a call to glGetIntegerv(<int> 0x8D57, <java.nio.IntBuffer> java.nio.DirectIntBufferU[pos=0 lim=2 cap=2]): GL_INVALID_ENUM ( 1280 0x500), 
at com.jogamp.opengl.DebugGLES3.writeGLError(DebugGLES3.java:8241)
at com.jogamp.opengl.DebugGLES3.glGetIntegerv(DebugGLES3.java:3476)
at processing.opengl.PJOGL.getIntegerv(PJOGL.java:1057)
at processing.opengl.PGL.maxSamples(PGL.java:2211)
at processing.opengl.PGL.createFBOLayer(PGL.java:881)
at processing.opengl.PGL.beginRender(PGL.java:721)
at processing.opengl.PGraphicsOpenGL.beginOnscreenDraw(PGraphicsOpenGL.java:6573)
at processing.opengl.PGraphicsOpenGL.beginDraw(PGraphicsOpenGL.java:1552)
@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Oct 12, 2015

Member

we shouldn't query the maximum number of samples if multisampling is not supported in the first place, see 9d6fc00. Does this change solve the problem?

Member

codeanticode commented Oct 12, 2015

we shouldn't query the maximum number of samples if multisampling is not supported in the first place, see 9d6fc00. Does this change solve the problem?

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Oct 12, 2015

Contributor

9d6fc00 fixes the regression, thanks @codeanticode!

Basics/Form/Primitives3D: display window is now all white after the first frame
Demos/Graphics/LowLevelGLVboInterleaved: works well (prints harmless glGetError 0x500 messages, will look into it)
Demos/Graphics/LowLevelGLVboSeparate: works well (glGetError 0x500)
Demos/Tests/NoBackgroundTest: works, except the background is white instead of red (as on OS X)
Demos/Tests/SpecsTest: works
Topics/Shaders/Monjori: works well
Topics/Shaders/Nebula: works

Contributor

gohai commented Oct 12, 2015

9d6fc00 fixes the regression, thanks @codeanticode!

Basics/Form/Primitives3D: display window is now all white after the first frame
Demos/Graphics/LowLevelGLVboInterleaved: works well (prints harmless glGetError 0x500 messages, will look into it)
Demos/Graphics/LowLevelGLVboSeparate: works well (glGetError 0x500)
Demos/Tests/NoBackgroundTest: works, except the background is white instead of red (as on OS X)
Demos/Tests/SpecsTest: works
Topics/Shaders/Monjori: works well
Topics/Shaders/Nebula: works

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Oct 12, 2015

Contributor

(think this can be closed now, will continue to track the overall 3D situation on the Pi - thanks guys)

Contributor

gohai commented Oct 12, 2015

(think this can be closed now, will continue to track the overall 3D situation on the Pi - thanks guys)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment