[glamo] accelerated primitives, superfast links2

3 messages Options
Embed this post
Permalink
mobi phil

[glamo] accelerated primitives, superfast links2

Reply Threaded More More options
Print post
Permalink
Hello,


As directfb seems to be very fast on openmoko, I am intending to write a few phone applications on top of it. I was thinking to write a directfb driver for it. However looking at the code of libglamo (mplayer) and Xglamo I see that not too many primitives are "accelerated". I see practically blit and mpeg decoding. Is there a way to access things like draw triangle/line etc?

By the way links2 is superfast on directfb and fb, even without acceleration for rendering.

--
rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Thomas White-2

Re: [glamo] accelerated primitives, superfast links2

Reply Threaded More More options
Print post
Permalink
On Tue, 22 Sep 2009 01:14:08 +0200
mobi phil <[hidden email]> wrote:

> As directfb seems to be very fast on openmoko, I am intending to write a few
> phone applications on top of it. I was thinking to write a directfb driver
> for it. However looking at the code of libglamo (mplayer) and Xglamo I see
> that not too many primitives are "accelerated". I see practically blit and
> mpeg decoding. Is there a way to access things like draw triangle/line etc?

The 2D engine only knows about rectangles and lines, although it also does
anti-aliasing of text and gradient fills if that's any help to you. Triangles
can be drawn via the 3D engine, but the overheads involved in programming all
the necessary parameters (transformation matrices, shading parameters, etc)
might make it not worth the effort.  But they might not, especially if you're
clever about how you program it.

> By the way links2 is superfast on directfb and fb, even without acceleration
> for rendering.

Indeed.  While our bus to Glamo is slow, it's not *that* slow.  This kind of
thing is great for getting an idea of what the underlying "Glamo factor"
really is, at least as far as pure graphics performance is concerned.

If you're interested in using Glamo's features, the DRM-enabled kernel (branch
drm-tracking) should be of interest to you.  All the command queue handling
and memory management is done for you with that, similar to libglamo but with
the option of having multiple programs accessing the chip simultaneously.
Maybe that's not of any help in the DirectFB environment, but if it is then
let me know if I can be of any assistance.

Tom

--
Thomas White <[hidden email]>

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
mobi phil

Re: [glamo] accelerated primitives, superfast links2

Reply Threaded More More options
Print post
Permalink
Hello,

unfortunatelly there is not too much docu out there about DRM, KMS and particulary about the architecture and interface to DRM and DRM for glamo. 

I am not that much interested about the impl. details but about the interface DRM provides, in order to asses the effort to write a driver for directfb.


Regards
mobi phil



On Tue, Sep 22, 2009 at 4:38 PM, Thomas White <[hidden email]> wrote:
On Tue, 22 Sep 2009 01:14:08 +0200
mobi phil <[hidden email]> wrote:

> As directfb seems to be very fast on openmoko, I am intending to write a few
> phone applications on top of it. I was thinking to write a directfb driver
> for it. However looking at the code of libglamo (mplayer) and Xglamo I see
> that not too many primitives are "accelerated". I see practically blit and
> mpeg decoding. Is there a way to access things like draw triangle/line etc?

The 2D engine only knows about rectangles and lines, although it also does
anti-aliasing of text and gradient fills if that's any help to you. Triangles
can be drawn via the 3D engine, but the overheads involved in programming all
the necessary parameters (transformation matrices, shading parameters, etc)
might make it not worth the effort.  But they might not, especially if you're
clever about how you program it.

> By the way links2 is superfast on directfb and fb, even without acceleration
> for rendering.

Indeed.  While our bus to Glamo is slow, it's not *that* slow.  This kind of
thing is great for getting an idea of what the underlying "Glamo factor"
really is, at least as far as pure graphics performance is concerned.

If you're interested in using Glamo's features, the DRM-enabled kernel (branch
drm-tracking) should be of interest to you.  All the command queue handling
and memory management is done for you with that, similar to libglamo but with
the option of having multiple programs accessing the chip simultaneously.
Maybe that's not of any help in the DirectFB environment, but if it is then
let me know if I can be of any assistance.

Tom

--
Thomas White <[hidden email]>

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel



--
rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel