Just some background FYI: when I worked for Graphics Working Group, I
initiated the 'glproxy' project [1] for runtime detection of OpenGL/ES
backends, and the development paused in mid 2012 for missing enough
interest from the members.
[1] https://code.launchpad.net/glproxy
On Tue, 27 Nov 2018 at
The skia code is also hold in the chromium project. I used chromium web
browser to check the skia performance with some browser benchmarks.
I think pixman is also a good candidate for skia to benchmark toolchain.
Regards,
Jammy
On Tue, Mar 1, 2011 at 10:53 AM, Jim Huang wrote:
> On 1 March 201
On Thu, Feb 24, 2011 at 4:46 AM, Guilherme Salgado wrote:
> On Wed, 2011-02-23 at 10:09 +0800, Jammy Zhou wrote:
> > Hi All,
> >
> > For some upstream projects, we don't use git-send-mail to send patch
> > for review. Take KDE/Kwin project for example, post-revie
Hi All,
For some upstream projects, we don't use git-send-mail to send patch for
review. Take KDE/Kwin project for example, post-review and the
reviewboard[1] are used for patch review. How shall we handle such kind of
cases?
[1] https://git.reviewboard.kde.org/
Regards,
Jammy
On Wed, Feb 23, 2
ore on the xf86 side of things.. ie. to provide
> default implementations of xf86CrtcFuncsRec and xf86OutputFuncsRec
> functions..
>
> BR,
> -R
>
> On Wed, Feb 16, 2011 at 7:24 PM, Jammy Zhou wrote:
> >
> > There is already one KMS abstraction layer (libkms.so) in lib
To accommodate the fact of independent display controller and GPU components
in ARM SOC, it will be better if we can separate KMS from DRM both in kernel
space and user space (i.e, create a new drivers/video/kms directory for
kernel side, move KMS related code in libdrm to libkms in user space). Th
There is already one KMS abstraction layer (libkms.so) in libdrm, maybe it
can serve as what we needed.
Regards,
Jammy
On Thu, Feb 17, 2011 at 9:08 AM, Clark, Rob wrote:
> I'm still in the learning-as-I-go phase here, so definitely not ready
> to propose a solution, but it does seem to me like
graphics and multimedia, power management as well
On Wed, Dec 15, 2010 at 10:44 AM, Paul Li wrote:
> Hi,
>
>
>
> I am a fresh of Linaro and I want to know what software components
> Linaro focus on? I see Linux kernel, GCC, GDB, UBOOT on Linaro website, any
> others? Thank you.
>
>
>
>
On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse wrote:
> On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou wrote:
> >
> >
> > On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse
> wrote:
> >>
> >> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote:
> >
On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse wrote:
> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote:
> > On Monday 13 December 2010, Jammy Zhou wrote:
> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <
> linus.wall...@linaro.org>wrote:
> >>
&g
On Mon, Dec 13, 2010 at 11:18 PM, Arnd Bergmann wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
> > On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >wrote:
> >
> > > On 11 December 2010 22:41, Arnd Bergmann wrote:
> > >
> > > * amd-gpu -
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij wrote:
> On 11 December 2010 22:41, Arnd Bergmann wrote:
>
> * amd-gpu -- a single but huge driver for the GPU. As is normally the
>> case with GPU drivers, we can expect long discussions
>> before it will get considered for m
It's my pleasure. Thanks to the great help from Alexander and Alexandros,
and I'm glad to co-work with your guys. I believe we can get more
achievements in coming cycle. ;)
On Tue, Nov 16, 2010 at 8:32 PM, Alexandros Frantzis <
alexandros.frant...@linaro.org> wrote:
> On Tue, Nov 16, 2010 at 12:1
Hi Shawn,
For "console=ttymxc0" boot option used by mx51evk, there is a bug in
/bin/auto-serial-console, which has been fixed by Alexander in
linaro.overlay.
Could you please have a try with the changes below? Normally, we don't need
to input username/passwd for headless rootfs.
line #15 of auto
:
> On Sun, Sep 19, 2010 at 06:26:54PM +0800, Jammy Zhou wrote:
> > 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 ups
ctk_effect_xxx_paint() functions
Regards,
Jammy
On Sun, Sep 19, 2010 at 8:43 AM, Jammy Zhou wrote:
> Hi Alexander,
>
> Yes, I also noticed this in the clutter reference manual. But no matter
> cogl_flush() is called or not, the results are the same. I think the frame
> buffer relate
9a791927102de674829b184ee20c80411c58 Mon Sep 17 00:00:00 2001
From: Jammy Zhou
Date: Sun, 19 Sep 2010 16:22:29 +0800
Subject: [PATCH 1/1] cogl-framebuffer.c: GL_DEPTH_STENCIL not supported in gles
There is GL_INVALID_ENUM error for GL_DEPTH_STENCIL when call
glRenderbufferStorage() with OpenGL
gards,
Jammy
On Fri, Sep 17, 2010 at 9:57 PM, Alexander Sack wrote:
> Hi Jammy,
>
> On Fri, Sep 17, 2010 at 5:23 AM, Jammy Zhou wrote:
> > With the sequence above, the actor cannot be displayed on screen. But if
> I
> > replace clutter_actor_paint with raw gles
Hi Alexandros,
I think this patch is upstreamable.
Regards,
Jammy
On Fri, Sep 17, 2010 at 3:19 PM, Alexandros Frantzis <
alexandros.frant...@linaro.org> wrote:
> On Thu, Sep 16, 2010 at 01:25:26PM +0800, Jammy Zhou wrote:
> > I have found the point in cogl gles2
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 dep
prepared a clutter patch as attached.
Hi Alexandros,
Could you please add this patch to the clutter branch in your ppa?
Regards,
Jammy
On Wed, Sep 15, 2010 at 10:10 PM, Jesse Barker wrote:
> On Wed, 2010-09-15 at 20:58 +0800, Jammy Zhou wrote:
> > After debugging into glBindFramebuffer,
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.
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 wrote:
> Hi Jesse,
>
> Thanks for y
er
> 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,
> Jes
Hi Alexander,
On Tue, Sep 14, 2010 at 4:31 PM, Alexander Sack wrote:
> On Tue, Sep 14, 2010 at 9:38 AM, Jammy Zhou wrote:
> >
> > Issues Fixed:
> > + Normalize clutter vetex positions to adapt to the vertex shader
> > + Use GL_TRIANGLE_FAN to implement original used
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
ilar
as MxToolkit used in Meego.
The bzr branch for clutk:
https://code.launchpad.net/~jammy-zhou/clutk/gles2-shaders.hacky
It's appreciated that you can give some suggestions. :)
Regards,
Jammy
On Tue, Sep 7, 2010 at 4:03 PM, Alexandros Frantzis <
alexandros.frant...@linaro.org> wrot
ers/mxc/amd-gpu folder, I think
Regards,
Jammy
On Wed, Aug 25, 2010 at 5:40 PM, Robert Schwebel
wrote:
> On Wed, Aug 25, 2010 at 05:34:37PM +0800, Jammy Zhou wrote:
> > For accelerated graphics on MX51 (Z430 and Z160), the kernel module
> > driver has been open sourced recently, b
For accelerated graphics on MX51 (Z430 and Z160), the kernel module driver
has been open sourced recently, but for user space libraries, they are still
proprietary, and NDA is needed to access source code as well as related
documents.
Regards,
Jammy
On Wed, Aug 25, 2010 at 3:02 AM, Scott Bambroug
29 matches
Mail list logo
