Hi Alexandros,
I found a bug in clutter for gles. And I have prepared a patch as attached.
Could you please add it to our clutter branch? I think this patch should
also be upstreamable.
By the way, could you please give some tips here to contribute to the
upstream clutter?
Regards,
Jammy
Hi,
I am porting clutter toolkit (clutk) to gles2. I found some problem between
clutter/cogl rendering and raw gles2 rendering as mentioned below. It's
appreciated that you can give some suggestions.
In part of ctk_effect_blur_paint() function, we do as following
- create fbo with texture and depth buffer (raw gles2)
- switch to this new fbo for rendering (raw gles2)
- call clutter_actor_paint to render the actor to texture (clutter/cogl)
- switch back to default frame buffer (raw gles2)
- render above texture on screen for display (raw gles2)
With the sequence above, the actor cannot be displayed on screen. But if I
replace clutter_actor_paint with raw gles2 rendering to paint a simple
triangle, the triangle can be shown correctly. So I guess
clutter_actor_paint didn't render to the new created fbo. is it related to
the cogl fixed pipeline?
Thanks in advance!
Regards,
Jammy
Hi Sachin,
I have summarized current status of clutk porting below, and if you have
time, we can check the left issues together as we discussed in the conf-call
yesterday. I think the issue marked with yellow has highest priority
currently.
Branch:
+ https://code.launchpad.net/~jammy-zhou/clutk/gles2-shaders.hacky
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
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.
+ 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
+ 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.
Regards,
Jammy
**
So I've been having some difficulty following the instructions to build
and boot an OMAP linaro image for qemu here:
https://wiki.linaro.org/Source/ImageInstallation
Following the instructions, I can build the image, and boot it. Uboot
works fine, and the kernel begins to load, however it seems to hang
after the following on the serial line:
[ 3.416564] OMAP DISPC rev 3.0
[ 3.417175] OMAP VENC rev 2
[ 3.768157] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 3.794738] serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a 16550A
[ 3.827117] serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a 16550A
[ 3.844787] serial8250.2: ttyS2 at MMIO 0x49020000 (irq = 74) is a 16550A
[ 3.851776] console [ttyS2] enabled, bootconsole disabled
[ 3.851776] console [ttyS2] enabled, bootconsole disabled
[ 3.984436] brd: module loaded
[ 4.059204] loop: module loaded
[ 4.086456] omap2-nand driver initializing
At first I suspected the console was just sitting on ttyS2, and the
serial port in qemu was ttyS0. So I mucked around with qemu's serial
port settings, but no-matter the config, I didn't see any other output.
I then tried to force uboot to set the console line to ttyS0, but the
boot.scr script uboot loads seems to overwrite any environment values
(trying to write my own boot line from the pre-boot.scr environment
values didn't boot either).
So I finally just hacked the linaro-media-create script to use ttyS0
instead of ttyS2, and there I found the console output stopped
immediately after the "console [ttyS0] enabled, bootconsole disabled"
message. So that doesn't seem to be the issue.
So now I'm suspecting I'm hitting some other hang. Does anyone else have
a working qemu omap environment that they are using to test the linaro
images? Are there any extra steps that need to be documented?
thanks
-john
The following changes since commit 6705d62756af1ddb4f46a8601d955334ec8fc96c:
John Rigby (1):
LINARO: Linaro-2.6.35.1005.10
are available in the git repository at:
git://git.linaro.org/ubuntu/linux-meta-linaro.git master
John Rigby (1):
LINARO: Linaro-2.6.35.1006.11
meta-source/debian/changelog | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
I think that it is easier to describe situation in email then on irc.
Currently there are 4 packages related to cross compilation support:
- armel-cross-toolchain-base (a-c-t-base in short)
- gcc-4.4-armel-cross
- gcc-4.5-armel-cross
- gcc-defaults-armel-cross
Each of them got into archive but they need to be updated to get installable
packages.
Status of each package:
1. a-c-t-base is at 1.47 in archive and was built from gcc-4.5-source
4.5.1-6ubuntu1 version. This package is used to bootstrap armel cross
toolchain and generates:
- binutils-arm-linux-gnueabi (from binutils-source)
- libc6(-dev,-dbg)-armel-cross (from eglibc-source)
- linux-libc-dev-armel-cross (from linux-source-2.6.35)
- gcc-4.5-arm-linux-gnueabi-base, libgcc1(-dbg)-armel-cross (from
gcc-4.5-source)
libgcc1* packages have /usr/share/doc/ directories as symlinks to
/usr/share/doc/gcc-4.5-arm-linux-gnueabi-base/
I have a version which does not provide gcc-4.5-arm-linux-gnueabi-base
package, libgcc(-dbg)-armel-cross depends on gcc-4.5-base and have
/usr/share/doc/ directories pointing into gcc-4.5-base one. Need to fix
this symlink by providing those files in libgcc1 package instead.
2. gcc-4.4-armel-cross is at 1.36 in archive and was built with gcc-4.4-source
4.4.4-14ubuntu4 version. This package provides compilers,
libstc++6-4.4-(dev,dbg,pic)-armel-cross, libmudflap0-4.4-dev-armel-cross
and gcc-4.4-arm-linux-gnueabi-base packages.
I have 1.38 version ready to upload which fixes #637454 #640298 bugs.
3. gcc-4.5-armel-cross is at 1.35 in archive and was built with gcc-4.5-source
4.5.1-7ubuntu1 version. This package provides compilers and runtime
libraries. But it does not provide libgcc1(-dbg)-armel-cross and
gcc-4.5-arm-linux-gnueabi-base because they are in a-c-t-base source
package. All resulting packages have /usr/share/doc/ directories pointing
into gcc-4.5-arm-linux-gnueabi-base one which is policy violation.
I have 1.37 version ready to upload which fixes #637454 #640298 bugs and
provides gcc-4.5-arm-linux-gnueabi-base package so policy violation is
removed.
4. gcc-defaults-armel-cross is at 1.3 in archive and does not require any
changes.
Main problem is that packages generated from gcc-4.5-source are split into two
packages: armel-cross-toolchain-base (libgcc1(-dbg)-armel-cross) and
gcc-4.5-armel-cross (all the rest). This was required to allow to bootstrap
cross compiler but gives problems when one is built with other version of
gcc-4.5-source then other - resulting packages are not installable (we have it
now in archive). It is also a thing which Matthias does not like and I
understand it. For now my only solution is to build both with one version of
gcc-4.5-source.
What are your opinions?
http://marcin.juszkiewicz.com.pl/download/ubuntu/ is download link for
mentioned versions.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
The weekly report for the Linaro Infrastructure team may be found at:
Status
report:https://wiki.linaro.org/Platform/Infrastructure/Status/2010-09-09
Burndown
chart:http://people.canonical.com/~pitti/workitems/maverick/linaro-infrastr…
The burndown chart is showing that number of work items has increased,
with a number of work items completed. This is showing that the number
of work items to complete is slipping further behind the trend line.
* Merged XML-RPC API and client and various fixes to them
* Got initial set of views into trunk. Currently this adds support
for browsing streams. While simple, it paves the way for more views (the
task is simple and repetitive) as we support authentication, unit tests
and other goodness that made it take longer.
* Got generic databrowser merged. This allows anyone to browse
everything that is in the database (so any bundles/tests that are
already in can be accessed without extra effort). This will act as a
temporary view layer before we can iron out what people actually want
from us.
* "Decide on dependency management approach (debs/buildout/...)": DONE
* "Implement dependency management": DONE.
* HardwarePacks: hwpack-install: landed and fixed a couple things
reported by asac
Please let me know if you have any questions.
Kind Regards,
Ian
