Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> 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
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
