Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

Mon Nov 17 10:49:45 CET 2008

On Mon, 17 Nov 2008 02:40:19 -0500 "Lally Singh" <lally.singh at gmail.com>
babbled:

> Well then,
> 
>   Therein lies the question, how long is OM going to be using the
> Glamo?  There's apparently some real potential in the device, but
> that's really measured as much by the chip's relevance as its
> functionality.

this is the problem. glamo is not used anywhere else on any linux/x running
devices. it's a one-shot wonder so far in the gta02. as best i know there are
no plans to use it again. it's an end-of-life chip anyway - it's old and has
been out for a long time so even if you wanted to - it may not be available
anymore in the near future (unknown - but likely scenario).

in the end - you need to weigh up effort vs. return on effort. the glamo itself
actually is quite limited. trust me. when i first just read the "bullet point
featurelist" i too was excited... then i actually read all the nitty details
and the gotchas, the "only in this situation", "only with these inputs or
outputs" or "only within these parameters" and my excitements dwindled very
quickly. you'll have to jump through some nasty hoops just to get a bit more
accel - and as i made a bet long ago, and i still stand by it. you'll spend a
lot of code doing a lot of "acceleration" and you will actually... not be
faster. for most things. the only thing that has anything of vague interest is
opengl-es - and even then here are some bullet points for limitations:

1. 256x256 max texture size (for vga and 2d this is just appaling in this day
and age)
2. max output buffer 511x511 (that means... qvga boys. and right now.. qvga
doesn't even work as the pixel timings aren't right).
3. no render-to-texture
4. texture uploads are slow (7m/sec) combined with only 8m video ram
5. if you saw the 3d docs... they are scant at best (register names pretty
much) and not much else.

now add to this having to merge it with 2d (texture allocation shared with
pixmap), the only thing i see gl being useful for is some limited 3d games that
are fullscreen (drop to qvga). qvga on the lcd actually looks rather awful
(very blocky) as well...

i'm not saying don't do it. i'm saying you need to look at what you have, the
effort needed, the return on effort, the results, and the "future".

>   The GTA02's been on the brink of obsolescence since the day it was
> introduced.  It can't even take most modern (3G) SIMs.  If the Glamo
> (or something compatible) is going to be around for a while, either in
> a long production life of the GTA02, or in newer phones, then all this
> makes sound engineering sense to work on.
> 
>   Otherwise, I have real doubts about the longevity of a software
> project aggressive enough to attempt major work (e.g. accellerated
> OpenGL) on this chip.  Lots of open source projects start off with a
> bang of enthusiasm, and die with a whimper.  If the chip's gone in a
> few months, I don't think we'll see the project survive.
> 
>   Hence, my earlier suggestion on just using the acceleration for some
> Gtk operations.  Small, effective changes.  Get that done to make the
> device feel responsive.  If someone wants to do the big OpenGL
> implementation later, fine, use this Gtk work as a sandbox for getting
> a feel for the device.

this is the thing.. the drvier is ALREADY doing this. i repeat this
ad-nauseum. the acceleration is the same u get in the "nv" driver or you saw a
few years back in the i8xx drivers etc. you get blit and fill accelerated (the
most common x ops). xvideo is accelerated. the only thing not is anti-aliases
font drawing and as such the glamo doesnt support this fully - u need to do
some hacks to pretend it will (like expand fonts to ARGB32 in software) and
from the look of it the expansion and then upload of pixels will likely net you
zero speedup as this extra cost will negate the speedups you get. imho glamo is
right now about as fast as u'll ever likely see it (imho). you can go sink a
mountain of work and as per the example above.. see no return. the ONLY thing
that i can see it might be worth it is opengl - and even then its a very weak
opengl accelerator with lots of gotchas.

all of the above of course is "in my opinion". it's based from years of doing
graphics - software and hardware and with x, and having read all of the glamo
docs.

the original hope was to do the most urgent acceleration that can be done
cleanly and get "90%" done (which is where it is at), and then open the docs so
people can tweak - thats the point of an open device. openmoko can't go
supporting some ancient device forever and ever - in 3 years will people still
be demanding updates and support? thats the point of it being open - you can
support yourselves via community. the problem is the fact that the docs are not
open to allow this to happen so there is a problem here.

i know so many of you are all excited over "Accelerating glamo" - it's already
done (for 2d) as much as is probably practical for x11 that will get you
speedups. 3d is possible but with a hefty list of limitations and a lot of
ugliness. if there was a glamo2 in the future and glamo3/4 coming out with
fixes/speedups/improvements... things would be different. as such i can't see
that happening.

>   $400 for a phone is a reasonable investment.  But months of work in

actually it's 1/2 what an iphone costs... so its fairly cheap. :)

> one's spare time is much bigger.  Before anyone commits to a
> large-scale project, I think it's fair to ask OM what their plans are
> with this chip.

a very wise suggestion :)

> -ls
> 
> On Sun, Nov 16, 2008 at 11:43 PM, Neng-Yu Tu (Tony Tu)
> <tony at openmoko.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >> Those are some good questions.  From what I understand the Glamo is
> >> fixed-function and supports OpenGL ES 1.1.  As far as changing Xglamo to
> >> be based on X over kdrive, I think to start, it would be best to leave
> >> Xglamo the way it is and just add-in OpenGL ES support, but if there
> >> were people dedicated to getting X support I would vote for it.
> >>
> >
> > Glamo3363 support:
> >
> > * OpenGL ES 1.0
> > * OpenGL ES 1.1
> > * Mobile D3D
> >
> > 3D pipe line:
> >
> > * transform
> > * cull
> > * lighting
> > * clipping
> > * setup
> > * rasterizer
> >
> > The glamo datasheet is full of register settings, as wolfgang said, we
> > hope could resolve this NDA issue in someway that could help people
> > develop 3D development on FR.
> >
> > - --
> > Neng-Yu Tu (Tony Tu)
> > Openmoko, Inc.
> > Support.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iEYEARECAAYFAkkg9oEACgkQmV6sZhhBn2+FKQCgq+A2HsKkNTlKHvZgi/zjlale
> > qXsAn2gi5L3cc0/SKjYF54ve6KtzIABW
> > =fJkN
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Openmoko community mailing list
> > community at lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >
> 
> 
> 
> -- 
> H. Lally Singh
> Ph.D. Candidate, Computer Science
> Virginia Tech
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
> 

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