clutk status update 2010/09/14
jammy.zhou at linaro.org
Wed Sep 15 02:19:57 BST 2010
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).
On Wed, Sep 15, 2010 at 5:22 AM, Jesse Barker <jesse.barker at arm.com> wrote:
> 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?
> 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 <asac at linaro.org>
> > wrote:
> > On Tue, Sep 14, 2010 at 9:38 AM, Jammy Zhou
> > <jammy.zhou at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linaro-dev