----- Original Message -----
From: "Tom Cooksey" <tomcook...@googlemail.com>
To: <beagleboard@googlegroups.com>
Sent: Sunday, September 28, 2008 1:06 PM
Subject: [beagleboard] Re: xserver with hw-acceleration for OMAP3?

> Writing an accelerated X server for the SGX is pretty easy. The SGX
> has a 2D core for blitting (with scaling & alpha blending). There's
> also a pretty nice API to the blitting hardware provided by the
> libpvr2d.so library. The problem is that you need to sign an NDA with
> ImgTec to get the headers for the pvr2d library. :-( I guess you could
> dump the symbols from the library and reverse engineer a header. The
> pvr2d library is what the WSEGL libraries use to blit the GL/VG back
> buffer into the frame buffer. It also allows chaining buffers for
> full-screen applications (so a eglSwapBuffers really does swap the
> buffers as opposed to doing a blit). This is what we use for the QWS
> (Qt Window System) EGL backend (Which should appear in the Qt
> snapshots sometime next week if anyone's interested).

> In addition to the NDA issue, another problem is that the pvr2d API
> takes physical addresses of the memory you want to blit. Normally you
> ask pvr2d to allocate the memory for you (in which case you don't need
> the physical address). But to get a composition manager to work with
> GL, you need to allocate memory in one process and use it in another
> (I.e. allocate in x server and use in client). I have no idea how
> you're supposed to allocate a hunk of memory, pin it and then get the
> physical address of it from user space. The idea I've been kicking
> around is to "reserve" say 8MB of ram for graphics. I think this can
> be done by passing a parameter to the kernel which tells it the
> physical address of memory it can use. You just pass in the physical
> address of the RAM, minus the top 8MB. Once you've made sure the
> kernel's never going to touch the top 8mb of physical RAM, you can use
> it for the SGX and even mmap it through /dev/ram. Anyone know if this
> is likely to work?

> BTW: Gallium3D's SGX drivers are for the SGX in Intel Atoms. As far as
> I know, TI have no plans to licence the Gallium3D driver from TG -
> Which means we're stuck with the ImgTec binary drivers with almost no
> X integration. :-(

> If anyone's interested in running QWS on the beagle, let me know -
> however I guess all the BeagleBoard people are focussed on X11 & GTK+?
> Even so, taking a look at the QWS integration might shed some light on
> things. BTW: I also wrote a backend for EGL on X11 for Qt if anyone
> wants to give it a try. If you're feeling _very_ adventurous you can
> even try out my OpenGL ES 2.0 paint engine (Not for the faint of heart
> - it's a bit buggy at the moment but should be stable for Qt 4.5.0,
> whenever that gets released.)

> Cheers,

> Tom

> On 9/26/08, Prabu <prabi...@yahoo.com> wrote:

>> If you are into text, it is better to use the VG support on the SGX.
>> An interesting option would be if we can have multiple passes :: VG
>> accelerated text using OpenVG on SGX->buffer, buffer->graphics
>> accelerated with OpenGLES on SGX->buffer -> display.  Need to do more
>> profiling.

>> Anyone have a working Cairo build with OpenGLES enabled ? I am
>> beginning to work on one, but wanted to check before in this thread.

>> On Sep 25, 10:15 pm, Diego Dompe <diego.do...@ridgerun.com> wrote:
>>> Hi Guo,

>>> On Sep 25, 2008, at 10:58 AM, guo tang wrote:

>>> > Could you elaborate clutter approach more?  If I only want to run one
>>> > special application (no need for windows manager here), and I don't
>>> > have the burden of running traditional X-window based application.
>>> > Will clutter be a good choice. How far away is clutter from metal?
>>> > Clutter -> openGL dirver -> PowerVR 530 -> Display ? No heavy
>>> > x-protocol in the chain?

>>> Yes, clutter is a good choice here.

>>> The layout will be:

>>> Clutter -> OpenGL ES -> Video hardware.

>>> Clutter provides text rendering using fontconfig and pango, so you
>>> have all the goodies for text rendering as normal Linux applications
>>> (i18n support, bi-directional support, etc), and you can stack up some
>>> more libraries on top of it like cairo and gstreamer to render
>>> directly from them to actors in 3D space.

>>> At this point it clutter only provides input using tslib for
>>> touchscreens when using the EGL backend, but I'm working in adding a
>>> generic Linux input event so you can use mouses or keyboards or keypads.

>>> What clutter doesn't provide is an elaborated toolkit for rich-text
>>> boxes or tree views. However you can use the webkit actor for complex
>>> text rendering.

>>> Regards,

>>> Diego.