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.
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
