On Wed, 2010-09-15 at 20:58 +0800, Jammy Zhou wrote: > After debugging into glBindFramebuffer, the error is not for this API > call. And the GL_INVALID_OPERATION error should be caused by previous > opengl call, for which CheckGLError is not called.
Glad to hear it. It would otherwise have suggested a potential implementation problem as the spec doesn't define that error for that situation. cheers, Jesse > > Regards, > Jammy > > On Wed, Sep 15, 2010 at 9:19 AM, Jammy Zhou <jammy.z...@linaro.org> > wrote: > Hi Jesse, > > Thanks for your point. I can confirm that the fbo extension is > available there for this functionality, and there is no such > error messages when call the same function in other clutk test > cases. And yes, the run-time check for the fbo capability is > not implemented, it is assumed that this extension is > supported by default now (It should not be a problem for > opengl es2.0 driver with fbo extension supported, I think). > > Regards, > Jammy > > > > On Wed, Sep 15, 2010 at 5:22 AM, Jesse Barker > <jesse.bar...@arm.com> wrote: > Jammy, > > With respect to the CheckGLError assertion in > test-clutk-perf, assuming > that glGetError is called per OpenGL entry point (i.e. > you are not > seeing an error triggered by another call), the only > way you should be > seeing an invalid operation when setting framebuffer > binding(s) back to > the default (glBindFramebuffer(GL_FRAMEBUFFER, 0)) is > if the framebuffer > object extension functionality is simply not there > (your OpenGL or GLES > implementation is too old). I notice that the > 'WITH_GLES' paths have > fewer checks for capabilities. Is it possible that > the code is simply > not checking at the moment? > > cheers, > Jesse > > > On Tue, 2010-09-14 at 17:23 +0800, Jammy Zhou wrote: > > Hi Alexander, > > > > On Tue, Sep 14, 2010 at 4:31 PM, Alexander Sack > <a...@linaro.org> > > wrote: > > On Tue, Sep 14, 2010 at 9:38 AM, Jammy Zhou > > <jammy.z...@linaro.org> wrote: > > > > > > Issues Fixed: > > > + Normalize clutter vetex positions to > adapt to the vertex > > shader > > > + Use GL_TRIANGLE_FAN to implement > original used GL_QUADS > > primitive, which > > > is not supported by gles2 > > > + Comment out cogl_flush() call in some > functions (such as > > > ctk_effect_blur_paint) to make sure > following gles2 > > rendering can be shown > > > + Fix render to cached texture problems > > > > > > very nice. > > > > is the cogl_flash call comment something we > want to keep or > > does that > > show an underlying issue we should try to > fix? > > > > [jammy] Because cogl_flush is implemented based on > fixed pipeline, if > > we want to really fix it, we may need to use cogl > for gles2 support in > > clutk, I think. So I just comment out them in some > proper places for a > > workaround. > > > > > > > > > > > > Issues Left: > > > + run test-clutk, there is crash at > > "/Effect/Animation/Animation" test > > > suite. This issue has already been > reported by Alexandros, > > see > > > > https://bugs.launchpad.net/clutk/+bug/614415, and it > should > > be an upstream > > > problem. > > > > > > neil replied in the other mail thread and > has a patch for > > clutter that > > we should try. maybe see if that helps > > > > [jammy] I have tried the patch from Neil, and it > works, but now there > > is the same issue for glBindFramebuffer as mentioned > below at > > "/Effect/Animation/Signals" test suite when run > test-clutk. > > > > > > > > > + when run "test-clutk-perf 0 10 125 5 > single animated blur > > 0.3.2 GMA950 2.1 > > > 1 10", crash happens with following error > message. The error > > happens when > > > call glBindFramebuffer (GL_FRAMEBUFFER, > 0). > > > Clutk-WARNING **: [CheckGLError] > GL_INVALID_OPERATION error > > in File > > > ./ctk-render-target.c at line: 581 > > > > > > Is this a regression from our gles port? > e.g. if you run the > > same > > command with desktop gl does it work? > > > > [jammy] This is a regression from our gles port. > > > > > > > + the actor painting (i.e, > "paint_func(actor);" in > > ctk_effect_blur_paint) > > > seems independent from other gles2 > rendering, and it is not > > rendered into > > > cached texture for later display. This > means that we cannot > > add special > > > effects to the actor. > > > > > > Do you think its a bug that it is > independent from other > > rendering? > > what happens if we try to fix this? > > > > [jammy] I think it is not a bug, but incompatibility > between cogl > > rendering and our gles2 rendering. > > > > > > > > > > -- > > > > - Alexander > > > > > _______________________________________________ > > linaro-dev mailing list > > linaro-dev@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-dev > > > -- > IMPORTANT NOTICE: The contents of this email and any > attachments are confidential and may also be > privileged. If you are not the intended recipient, > please notify the sender immediately and do not > disclose the contents to any other person, use it for > any purpose, or store or copy the information in any > medium. Thank you. > > > > > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
