GTA03 graphic API discussion

Carsten Haitzler (The Rasterman) raster at
Tue Dec 9 13:38:08 CET 2008

On Tue, 09 Dec 2008 10:56:11 +0000 Andy Green <andy at> babbled:

the 2d on the 6400 is pretty decent - a far cry better than the glamo, but
still it has some funky limits you'll have to jump through some hoops to make
it work.

> Hash: SHA1
> 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
> s3c6400 datasheet
> which can be of interest about the 2D side anyway.
> jorgeluis.zapata at writes:
> | | ~ - 2D acceleration and 3D driver are separate issues... Juan is
> meant to
> | | 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
> (ch. 16)
> 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)
> Yep.
> |> 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
> Sounds encouraging.
> |> 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,
> |> qt).
> 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
> years ago.
> 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
> features)
> | 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 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,
> kms, etc).
> 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).
> - -Andy
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
> iEYEARECAAYFAkk+TssACgkQOjLpvpq7dMoSzQCdGb7gXTfR2bBZJ13Zz+jlE9uz
> BLwAnRdligqOr/WFUaV+1X+tNrrIFwdy
> _______________________________________________
> devel mailing list
> devel at

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at

More information about the devel mailing list