[maemo-developers] [maemo-developers] What is the 770 display hardware able to accalerate?

[From: Jari Kirma]

Gustavo Sverzut Barbieri <barbieri at gmail.com> wrote:
> On 11/7/05, Clemens Eisserer <linuxhippy at gmail.com> wrote:
> > Hi there,
> >
> > I just read that the 770 display hardware is quite slow but on the
> > other hand it supports pixel doubling which isn't such a trivial
> > feature at all.
> 
> I think you mis understood that mail.
> 
> 1) pixel doubling is trivial, instead of painting one pixel at (x,y),
> you paint 4 pixels at (2x,2y), (2x, 2y+1), ( 2x+1, 2y) and (2x+1, 2y+1
> ).
> 
> 2) dealing with large pictures, so much data, consumes lots of CPU
> cycles, that nokia 770 doesn't have (200mhz arm)
> 
> 
> > Does anybody know which operations are (at least partially)
> > accalerated by the integrated graphic controler - e.g. are
> > fills/draw/blit operations which are done by xlib accalerated?
> > Does the target surface play a role wether it can be accalerated (e.g.
> > can fills/blits to or from a pixmap be accalerated)?
> 
> I don't know, let someone that knows the hardware better reply this part.

Before I got my 770 today, I browsed through OMAP1710 documentation and related 
kernel sources. OMAP1710 claims to perform "2D graphics acceleration" according 
to marketing page, but in practice, this boils down to a very programmable DMA 
engine - it can perform, among other things, image rotation (for RGB, at 
least), blitting, color-masked blitting, and constant filling. OMAP1710 also 
has a reasonably powerful, and potentially very underused TI DSP counterpart 
which has specific accelerators, of which DCT decoding is probably of most 
interest (for video playback). I don't know how fast it could perform color 
space conversions.

I've heard that Nokia 770 doesn't use the built-in LCD controller in OMAP1710, 
but uses a specific chip for this purpose - supposedly to improve performance. 
Kernel source file drivers/video/omap/hwa742.c contains rather scantily 
documented code for this Epson chip, which obviously can perform color space 
conversion from YUV422 and YUV420 formats to native RGB. It also does the pixel 
doubling, and I have a hunch it can do other things, such as framebuffer 
rotation, but it's next to impossible to understand how that functionality 
could be programmed, since publicly available documentation is lacking.

I would be very glad to hear especially about HWA742, and especially regarding 
possibility to implement framebuffer rotation (also for non-RGB color spaces) 
on hardware to implement it efficiently on X11 (for instance, 180 degree 
rotation for left-handed users would be great).

Sadly enough, even though there are things that can improve certain scenarios, 
memory speed is probably the largest bottleneck.

-kirma