GTA03 graphic API discussion
andy at openmoko.com
Tue Dec 9 11:56:11 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
Two threads are going on internal list I will reply to combined here...
I am not at all an Xorg guy and for sure there will be better comment
out here especially considering the stuff going on around Glamo 2D and 3D.
I didn't find a public s3c6410 datasheet, but I did find a public
which can be of interest about the 2D side anyway.
jorgeluis.zapata at gmail.com writes:
| | ~ - 2D acceleration and 3D driver are separate issues... Juan is
| | be solving the 3D end but I am not sure there is actually a story about
| | 2D accelerated driver.
|> Hello Andy :)
| Hiya Jorge -
| I'm not sure how you're set up, AFAIK there is existing project to
| migrate GTA02 / Glamo to Xorg that Graeme had underway, hopefully that's
| your current plan.
| On the next product GTA03 the s3c6410 CPU on there has inbuilt 2D
| acceleration unit, but there is no software support available AFAIK. So
| it means we are missing a 2D Xorg driver for that product too. It
| basically has bitblt and alpha support, can draw some primitives like
| lines too: it can be enough to provide Xv functionality. The whole
| display unit on the CPU is based on shared memory architecture.
| We have fairly good data about this unit in the s3c6410 datasheet
| "Graphics2D" chapter 18:
|> Yeah i was searching for the datasheet the past days and i found it on
|> the internal mailing list ;)
|> About the different gfx possibilities the hw gives (matched against X
|> extensions), we have:
|> 1. Xv: YUV plane on the display controller (ch. 14) and tv scaler
FWIW TV Scaler for TV standards is dead to us because we don't have
anything hooked to TV IO nor do we have the 27MHz clk source for it.
|> 2. XRandR: The rotating feature on the Graphics2D (ch. 18) and the
|> Rotator (ch. 19)
|> 3. Xrender: alpha compositing on the Graphics2D (ch. 18) Graphics3D
|> (ch. 42) Thankfully this hw doesnt have those common 2d engines found
|> on embedded devices with limited operations which is totally useless
|> for modern GUI
|> If we want to continue on the "desktop" approach for gfx architecture
|> we must develop the above and stuck with X (both its features and its
|> flaws), i understand that from a community POV is good to keep
|> compatibility and standardization among embedded and desktop, but
|> honestly im not sure it is the best way to go, mainly because of the
|> specific hw features that we have (which might not fit correctly on
|> the X extensions) and the performance that we might be able to
|> achieve. For example the Xrender extension which allows transparency
|> and alpha compositing on drawing primitives is really, really slow and
|> mostly unused (but supported) on different gfx libraries (evas, gtk,
We have to think a bit bigger than the immediate situation in front of
us though... if you switch lenses and look at this at the widest angle
the rootfs-es based on this work can find themselves running on a bunch
of different devices, not just Openmoko ones.
The general trend is that devices are only getting stronger year by year
not weaker, and they are pretty much following the path of PCs some
For these reasons I think we are better off establishing a strong
standardized basis for the graphics work rather than trying to shave the
last 2% performance by going straight to framebuffer, or bending every
feature into it for today's situation. There's no doubt Xorg is the
real survivor when faced with bunch of different graphics architectures
and wide range of features exposed a common way.
(from a followup mail saying how not all hw features will map to Xorg
| from the hw features we are able to blit the uncompressed video frames
| into a hardware YUV plane and just setup a couple of registers to
| blend the GUI against that video. But from X there's no way to do that
| using the accelerated Xv extension, so the solution is to do or
| everything on software or everything on 3d accelerator using a
| texture, but maybe the 3d hw block is not enough for that job.
I'm replying to your other mail on the devel list, but about that
specifically, it's just another way to fail if we make wrong
architectural decisions as part of an impossible effort to tick every
box. The next hardware we look at will also have different features
that can't map on to Xorg structure either.
We are better off saying, well, I know you only bought this phone to get
transparent video playback :-) but in fact we support great fast
tear-free xv video playback by Xv, and fast cool transparency with
Xcomposite, just not both... and since it's all done using standard Xorg
stuff so it's easy to get apps like mplayer, gstreamer or whatever to
work with it without any hacking.
|> A little off topic, but Andy, if i understand correctly, you are a
|> kernel hacker right? What's your opinion of using UIO for specific hw
|> features? I've done that in the past and seems a good option.
So long as the kernel end of the UIO stuff is done properly (last "UIO"
type driver XGlamo did not take care of locking between kernel and
userspace well) then it can be fine.
Then turran at openmoko.org writes:
I've been reading the different hw blocks we have and there are for sure
several interesting things related to graphics/video:
- - MFC (multiformat video codec, ch. 21): This block can be coded using
Xorg's Xvmc extension for the dct, motion estimation, quantization, etc.
About the internal BIT processor, im not sure how to handle that.
- - Graphics2d (ch. 18) This block can support part of the Xorg's EXA API,
for example the compositing operations, which will make the Xrender
extension to be accelerated and in theory fast.
- - Display Controller (ch. 14) This block is able to do chroma keying
between video/gfx planes, so the X11's Xv extension fits perfectly here,
even so the alpha blending of different planes is not supported on any
Xorg's extension which is a nice feature.
There are other places were there is no matching API but the feature's
are promising, like the rotator, color space converter / scaler and jpeg
codec, maybe a purely UIO interface is needed there?
Also for the EXA extension we also have a 3d engine, not sure about it
tho, given the huge work that is done on that part on kernel side (drm,
I understand the current situation is mainly to focus on core parts of
the device and that we have limited number of boards. So this mail is
just about knowing what standard linux/xorg API's the device can use for
the different features it has.
So there seems to be a consensus forming there to use Xorg stuff
everywhere, UIO xorg driver, and we notice some features will fall
between the cracks (but I think this is fine so long as we deliver
solid, fast, quality core function via all the standard APIs).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the devel