Acceleration in our pockets

Carsten Haitzler (The Rasterman) raster at openmoko.org
Sat Jun 14 04:47:57 CEST 2008


On Fri, 13 Jun 2008 21:05:16 +0200 Rodolphe Ortalo <rodolphe.ortalo at free.fr>
babbled:

> Le vendredi 13 juin 2008 à 17:04 +0800, Carsten Haitzler a écrit :
> [...initial parts deleted for brevity...]
> > no problems. what i don't want is people to get their hopes up. this was in
> > the context of people asking if they can play vga video and me going "good
> > luck!". there is reality - and you can sit and hack away spend lots of time
> > and get 1 case to work, and work well. as i said - it will depend on codec,
> > bitrate, quality etc. mpeg4 decode in hw is great - but remember it is also
> > limiting to just mp4 - all your mpeg1, ogg, etc. videos will not work. also
> > as long as mplayer is accessing glamo hardware it must run as root.
> > admittedly we run everything as root - but come the day when we don't...
> > this is trouble.
> [...final parts deleted for brevity...]
> 
> With the glamo hw you can do mpeg4 decoding acceleration but not
> mpeg1/2?
> Isn't mpeg4 in hw theoretically more difficult (from the raw computing
> point of view) than mpeg1/mpeg2 decoding?
> 
> Just for curiosity of course.

in theory - absolutely right, BUT the glamo has a in-silicon  mpeg4 decoder
(which we haven't exported via any device driver or mechanism, as it has not
been on any list of priorities). there is no standard x-aware mechanism to
transport encoded streams via (we'd have to invent a new one or extend xvideo
in a non-standard way) ans so would involve much more thought and work than a
quick "lets just make a driver". so this in-silicon feature does mpeg4. that's
what it does. all it does. if it exposed a more generic dsp or decoder
subsystem it could be adapted to multiple codecs, but that is not the case. :(

> Anyway, out the video playback issue, I looked at some of this
> hw-specific code in the mplayer git branch or in Xglamo, it sounds
> pretty interesting. (I have played a lot with some graphic cards accel
> in the late 90s: Matrox or Cirrus Logic primarily.)
> 2D accel for example should really help the overall phone UI operation
> no?
> What is the overall objective on the Neo: have a glamo-specific X server
> using XAA and the like (hence an X driver), or implement most of the hw
> acceleration in the framebuffer device and use Xfbdev (hence a kernel
> driver), or something else (possibly more recent than my experience with
> this area ;-)?

xglamo. if you want to accelerate - do it in a way that will last beyond 1
hardware generation. if you go putting chip-specific hardware driving code in
applications you will crate long-term work. again and again. in future we may
have no mpeg4 or video accel. we may have different chips with greater or
lesser capabilities. there has been no resources assigned to addressing this in
a sustainable way so we can support codecs going forward as hardware may or may
not support them. (an example i heard of recently is openmax).

before long your apps carry the baggage of a decade of drivers for a mountain
of chipsets, when it should have been wrapped in a proper subsystem for doing
in-hardware codec playback. so far xglamo support standard mechanisms for video
accel - like xvideo yuv->rgb + scaling acceleration. that is as far as i can
guarantee support - as it is a standard mechanism that also works on your
desktop xserver and anywhere else. it is already well supported by players
(mplayer, xine, gstreamer etc.) and is simple. anything else is going to need
more work and thought.

one can always do a quick hack. then another. and another. and another. in he
end the mountain of hacks will cost a lot of time and effort- repeatedly, and
become a massive maintenance burden. what you want is a longer-term solution
that carries you into the future with less overhead in the long run. where you
cleanly implement a driver and anything using the abstraction api correctly
just "works" into the future. :)

-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>




More information about the community mailing list