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

[Nicola Mfb]

2008/11/21 Andy Green <[EMAIL PROTECTED]>

> Graeme seems to be planning to do his xorg version of Xglamo partially
> in kernelspace to unify the locking, that would be when to do this too.
>
> The Glamo's interrupt itself is supported and working, it's the basis
> for the same waiting strategy (yielding until completion interrupt) in
> the Glamo MMC stuff.
>
> - -Andy
>

This is great!

Thanks!

  Nicola
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| 2008/11/21 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]
| >
|
|
| XSync sends a request to x and waits for a reply - so your client
| app will stop
| and wait until x replies. x will reply once it has completed all
| existing
| requests - that means the XCopeArea. while your app is waiting
xglamo is
| waiting for the gfx chip to do the work - and likely its sitting in
| a loop
| polling checking when the command is done.
|
|
| Thanks Raster, now things are becoming clear :)
| The glamo chip should raise an interrupt when the command is done, a
| specialized kernel module should export this interrupt to the userspace
| so Xglamo may suspend waiting for this interrupt without wasting cpu
cycles!
| I suppose that this should be quite easy and cheap for Openmoko
| developers, may it be considered?
| This will really improve the device performance!

Graeme seems to be planning to do his xorg version of Xglamo partially
in kernelspace to unify the locking, that would be when to do this too.

The Glamo's interrupt itself is supported and working, it's the basis
for the same waiting strategy (yielding until completion interrupt) in
the Glamo MMC stuff.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkmvsIACgkQOjLpvpq7dMqv2ACeOBYzeq9vyfgisJSznt+Fr3HL
YCMAn1yqajW9/lTDFcnjcJVIhPJlkgnN
=oTbc
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Yorick Moko]

harald welte did good for via:
http://www.via.com.tw/en/resources/pressroom/pressrelease.jsp?press_release_no=2887
let's ship him to smedia :)

On Fri, Nov 21, 2008 at 2:02 PM, Nicola Mfb <[EMAIL PROTECTED]> wrote:
> 2008/11/21 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>
>>
>> XSync sends a request to x and waits for a reply - so your client app will
>> stop
>> and wait until x replies. x will reply once it has completed all existing
>> requests - that means the XCopeArea. while your app is waiting xglamo is
>> waiting for the gfx chip to do the work - and likely its sitting in a loop
>> polling checking when the command is done.
>
> Thanks Raster, now things are becoming clear :)
> The glamo chip should raise an interrupt when the command is done, a
> specialized kernel module should export this interrupt to the userspace so
> Xglamo may suspend waiting for this interrupt without wasting cpu cycles!
> I suppose that this should be quite easy and cheap for Openmoko developers,
> may it be considered?
> This will really improve the device performance!
>
> Regards
>
>Nicola
>
>
>
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Nicola Mfb]

2008/11/21 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>

>
> XSync sends a request to x and waits for a reply - so your client app will
> stop
> and wait until x replies. x will reply once it has completed all existing
> requests - that means the XCopeArea. while your app is waiting xglamo is
> waiting for the gfx chip to do the work - and likely its sitting in a loop
> polling checking when the command is done.
>

Thanks Raster, now things are becoming clear :)
The glamo chip should raise an interrupt when the command is done, a
specialized kernel module should export this interrupt to the userspace so
Xglamo may suspend waiting for this interrupt without wasting cpu cycles!
I suppose that this should be quite easy and cheap for Openmoko developers,
may it be considered?
This will really improve the device performance!

Regards

   Nicola
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Robert Schuster]

Hi,
all this talking without outcome is very boring to read. :|

I cannot help with the development of a free 3D-capable driver for the
Glamo directly instead I offer money!

As soon as cofundos.org is working again (I hope they haven't shut it
down) I will create a project and offer 50€ to the people who develop
that driver.

Of course, to make the money offer attractive some more people need to
join. That will be up to the community. Spread the word!

Regards
Robert



signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[The Rasterman]

On Fri, 21 Nov 2008 12:19:59 +0100 "Nicola Mfb" <[EMAIL PROTECTED]> babbled:

> 2008/11/20 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>
> 
> > it's accelerated - but likely polling the command queue status as you have
> > no
> > interrupts thanks to the linux kernel's policy of not exporting interrupts
> > to
> > userspace, so you're stuck with a poll loop. i can't remember if glamo had
> > a
> > "i'm done" interrupt for the command queue or operations - i know it had
> > several interrupts it can generate (but as the kernel wouldnt allow
> > userspace
> > to make use of them i pretty much ignored them).
> >
> 
> I'm not sure I understand completely, may you elaborate this?
> Profiling my loop:
>  {
> switch foreground paint color
> draw a vertical line from 0,0 to 0,639
> XCopyArea to scroll the screen 1 pixel right
> XFlush
> usleep(4) to have aproximately 25 fps
> }
> I got that:XCopyArea + XFlush are about 100 microseconds long, usleep is
> about 44000, and as the last is not cpu intensive this should results in a
> near 0% cpu busy. But as top reports 70% of cpu wasted by glamo (vmstat
> reports 25% user time and about 50% system time), I added after XFlush a
> call to XSync, and this reported another 4 microseconds wasted while
> waiting for X server to complete the request. As top reports again 70% of
> busy cpu I suppose that during the XSync the main CPU is working and suppose
> this is not only due to protocol latency and other overhead, but the glamo
> driver is doing some other things while the gpu is blitting.
> Is this the interrupt problem you are referring to?
> And if this is true would be possible to write a workaround?
> You are right, 2d is accelerated but this is unuseful if the cpu has to be
> busy while the gpu is working!

XSync sends a request to x and waits for a reply - so your client app will stop
and wait until x replies. x will reply once it has completed all existing
requests - that means the XCopeArea. while your app is waiting xglamo is
waiting for the gfx chip to do the work - and likely its sitting in a loop
polling checking when the command is done.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Nicola Mfb]

2008/11/20 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>

> it's accelerated - but likely polling the command queue status as you have
> no
> interrupts thanks to the linux kernel's policy of not exporting interrupts
> to
> userspace, so you're stuck with a poll loop. i can't remember if glamo had
> a
> "i'm done" interrupt for the command queue or operations - i know it had
> several interrupts it can generate (but as the kernel wouldnt allow
> userspace
> to make use of them i pretty much ignored them).
>

I'm not sure I understand completely, may you elaborate this?
Profiling my loop:
 {
switch foreground paint color
draw a vertical line from 0,0 to 0,639
XCopyArea to scroll the screen 1 pixel right
XFlush
usleep(4) to have aproximately 25 fps
}
I got that:XCopyArea + XFlush are about 100 microseconds long, usleep is
about 44000, and as the last is not cpu intensive this should results in a
near 0% cpu busy. But as top reports 70% of cpu wasted by glamo (vmstat
reports 25% user time and about 50% system time), I added after XFlush a
call to XSync, and this reported another 4 microseconds wasted while
waiting for X server to complete the request. As top reports again 70% of
busy cpu I suppose that during the XSync the main CPU is working and suppose
this is not only due to protocol latency and other overhead, but the glamo
driver is doing some other things while the gpu is blitting.
Is this the interrupt problem you are referring to?
And if this is true would be possible to write a workaround?
You are right, 2d is accelerated but this is unuseful if the cpu has to be
busy while the gpu is working!

Regards

Nicola
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| so right now other than bugs and trying to minimise cpu overhead on
handling
| the commandqueue 2d is done - it's not getting "faster". only thing
left is 3d.
| and that comes with a long list of gotchas. this is the bit where
someone needs
| to make a call on "what is the effort needed, and the result". this is
up to
| openmoko to decide what to do as the docs are in their hands. 2d is
pretty much
| done. :)

Having heard the down side :-) whatever else one can say about it
compared to other hardware, Glamo 3D unit is interesting for two
reasons: first the render work happens on the other side of the bus,
"past the bottleneck".  A large part of the 8MB on-chip memory is
available to hold assets that can be prepped beforehand, these can be
operated on by the 3D unit with no real CPU bus load.  Even allowing for
the constraints we can expect smooth 3D capability on the LCM from this
far beyond what software render could manage, and with the CPU able to
work in parallel.

The second reason is that if we leverage pure xorg -> Mesa -> OpenGL ES
basis for this implementation, the architecture of autonomous rendering
is very compatible with future products which will also feed themselves
from (shared) memory without heavy CPU involvement.  So we bring GTA02
up into being able to use OpenGL ES-based apps, games and UI we can
expect in future with minimal or no special-casing.

- -Andy

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkmjhsACgkQOjLpvpq7dMq30QCfVq1lx6s8nVxPGk1PEpotUz8/
1OQAn3eIm3LFHkAb0TsCDUeOsvhJbSRC
=ciVI
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Lally Singh]

On Fri, Nov 21, 2008 at 3:09 AM, Timo Jyrinki <[EMAIL PROTECTED]> wrote:
> 2008/11/21 Lally Singh <[EMAIL PROTECTED]>:
> 
>> I'm taking a protective role for the community in all this.  IMHO the
>> community's what makes the OM phone interesting.  I'd rather not see
>> well-intentioned hackers spend long months on a venture with little
>> likely return.
>
> This is something that depends on what the mentioned hackers want to
> do. It's not anyone else's job to tell others how to spend their free
> time. And also "little return" is quite relative. As for QVGA Glamo 3D
> support, I think it would be really worthwhile not only to have it,
> but to have the possibility to try out eg. Clutter-based applications
> during GTA02 lifeframe. It would benefit a lot also the future
> generations of Openmoko hardware.

I'm not stopping anyone, just making sure they know what they're getting into.

>> By the time the GTA03's entering its lifetime, hopefully there should
>> be some good options available.  I like the idea of one or more vector
>> units..
>
> I'm hoping that with the openness on the desktop side - AMD, Intel,
> Via and XGI, it cannot be indefinitely until there is also mobile
> graphics chipsets available with open documentation. It's not that
> much more special and on the desktop side you have already basically
> "everybody but one vendor" (nvidia).

-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Timo Jyrinki]

2008/11/21 Lally Singh <[EMAIL PROTECTED]>:
> As Raster's already pushed hard on Glamo acceleration, and I know he's
> quite capable (I was an old enlightenment WM user back in the day), I
> consider the glamo issue closed.  We're stuck with what we have, and
> simply have to find ways to be efficient with what what's already
> there.

Yes, efficiency, but let's remember the stable-tracking kernel has
Glamo core clock boosted from 50MHz to 80MHz with some wait states
disabled - it also does bring additional performance to play with /
optimize for. And I don't know what where the exact details for some
big (?) wait state somewhere in the driver that was earlier hoped to
be gotten ridden of, but which turned out not to be easy?

Something, somehow, is anyway hopefully fixable in addition to
boosting the clock speeds, since the CPU usage of using Glamo seems
quite ridiculous at times.

> I'm taking a protective role for the community in all this.  IMHO the
> community's what makes the OM phone interesting.  I'd rather not see
> well-intentioned hackers spend long months on a venture with little
> likely return.

This is something that depends on what the mentioned hackers want to
do. It's not anyone else's job to tell others how to spend their free
time. And also "little return" is quite relative. As for QVGA Glamo 3D
support, I think it would be really worthwhile not only to have it,
but to have the possibility to try out eg. Clutter-based applications
during GTA02 lifeframe. It would benefit a lot also the future
generations of Openmoko hardware.

> By the time the GTA03's entering its lifetime, hopefully there should
> be some good options available.  I like the idea of one or more vector
> units..

I'm hoping that with the openness on the desktop side - AMD, Intel,
Via and XGI, it cannot be indefinitely until there is also mobile
graphics chipsets available with open documentation. It's not that
much more special and on the desktop side you have already basically
"everybody but one vendor" (nvidia).

-Timo

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Lally Singh]

Wolfgang, Raster:

On Thu, Nov 20, 2008 at 11:28 PM, The Rasterman Carsten Haitzler
<[EMAIL PROTECTED]> wrote:
>> >  The GTA02's been on the brink of obsolescence since the day it was
>> > introduced.
>> Don't agree with you. In the long run everything is obsolete.
>
> i think he is referring to using an "old soc", "old gfx chip" etc. something
> that has been out for many years - where the "competition" (not in open 
> phones,
> but in phones in general) is busy building new devices on chips not yet in 
> mass
> production as they follow the curve and by the time it is in production - 
> their
> device is ready. it's perfectly understandable why openmoko is building on an
> old platform - but it still makes the hardware very much "behind the curve" :)

I suspect the Glamo was designed for a much less sophisticated setup,
with a lower-res screen and probably a slower CPU.  Hence the texture
sizes and I/O speed limitations -- choices made for cost & power.

> 
>> > 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,
>> Long production life of GTA02.

I'm all for longer production lives.  But, IMHO in the next
incarnation, some more thought to a longer useful life  should be
given.  Specifically, a few more ports on the device are necessary to
keep its useful life long.  LInuxer's will add drivers for new devices
as they come, extending the life of the device, but we need I/O.

Additionally, the components chosen shouldn't be as overtaxed from the
beginning as the glamo.  Only after the driving software has been
written does a team find out the real limitations of the device.
Started from a burdened position usually only leads downward after
trying to get aggressive on the software side.  IMHO 3D was/is a great
idea, so I can't blame OM for trying with the glamo.  But there are
alwasy some lessons to come out any development effort.

Finally, the next device should have stable support for basic phone
operation when it's released: suspend, resume, calling, and
answer-while-suspended.  Without that, it's hard to get the
imagination going for what else to do with the phone.  The GTA02's
release should have been in two phases for hackers and users.  The
former as it was, the latter after those functions were stable.  If
that's not possible for the GTA03, then a two-phase release is
appropriate for it, too.  The nice consequence of it is that it brings
in larger community participation of the device's commercial
lifecycle, which will lead to a better feeling of community ownership
over it.

I admit I was quite embarrassed to show the device off upon reception,
considering how really raw it was.  I'm happy with the results of the
optimization team, and it looks like OM's going the right way now.
But it was quite painful for too long, and shouldn't be repeated.

>> >  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.
>> Very good idea. I always prefer breaking a large idea into smaller
>> pieces.
>
> one thing everyone seems to think that is wrong. this "gtk acceleration" is
> already done. blits, fills. xvideo too. :) 
>
> so right now other than bugs and trying to minimise cpu overhead on handling
> the commandqueue 2d is done - it's not getting "faster". only thing left is 
> 3d.
> and that comes with a long list of gotchas. this is the bit where someone 
> needs
> to make a call on "what is the effort needed, and the result". this is up to
> openmoko to decide what to do as the docs are in their hands. 2d is pretty 
> much
> done. :)

As Raster's already pushed hard on Glamo acceleration, and I know he's
quite capable (I was an old enlightenment WM user back in the day), I
consider the glamo issue closed.  We're stuck with what we have, and
simply have to find ways to be efficient with what what's already
there.

>> 1. We currently are disappointed about s-media. To be fair to them I
>> do not want to quote from contracts we have with them, but let me tell
>> you at the bottom line we feel there have been some broken promises
>> with regards to opening documentation.
>> 2. Because of this situation, we decided to not use s-media chips in
>> future Openmoko products.
>> 3. At the same time, we decided to not come out with GTA02 versions
>> that had the glamo removed, because that would have been hard to do
>> technically, and it would have created too much technical fragmentation.
>> 4. Even with raster's bashing, the glamo chip is a really nice mobile

That isn't stuff you could've known before committing this far.  I'm
sorry it happened to a platform I like so much.  I support your
decision of keeping it in, otherwise you'd lose a lot of your
community

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

[The Rasterman]

On Fri, 21 Nov 2008 11:59:42 +0800 Wolfgang Spraul <[EMAIL PROTECTED]>
babbled:

> Lally,
> 
> > how long is OM going to be using the Glamo?
> The glamo will be kept for the lifetime of gta02, i.e. every gta02  
> will have the glamo chip.
> For gta03, release date unknown, the decision is to not have a glamo,  
> we use the acceleration of the SoC.
> 
> >  The GTA02's been on the brink of obsolescence since the day it was  
> > introduced.
> Don't agree with you. In the long run everything is obsolete.

i think he is referring to using an "old soc", "old gfx chip" etc. something
that has been out for many years - where the "competition" (not in open phones,
but in phones in general) is busy building new devices on chips not yet in mass
production as they follow the curve and by the time it is in production - their
device is ready. it's perfectly understandable why openmoko is building on an
old platform - but it still makes the hardware very much "behind the curve" :)

> GTA02 is a real pioneering device for Linux in mobile phones, and is  
> still advancing the state of Free Software in mobile phones in many  
> areas.
> We owe the community better hardware, and have made decisions  
> internally to only focus on hardware and lower-level software.
> But that will not remove the pioneering status of GTA02, not even when  
> GTA03 ships, again release date unknown at this point.
> 
> > It can't even take most modern (3G) SIMs.
> Thanks to great work from Dieter, Joerg and Werner, this bug (trac  
> #666) seems to be fixed now, GSM reflash utility and instructions are  
> available, etc.
> Next they target trac #1024 (network re-registration).
> 
> > 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,
> Long production life of GTA02.
> 
> >  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.
> Very good idea. I always prefer breaking a large idea into smaller  
> pieces.

one thing everyone seems to think that is wrong. this "gtk acceleration" is
already done. blits, fills. xvideo too. :) aa text isn't possible as the glamo
doesn't meet xrender specs for doing aa text, so it's software or bust (unless
you upload ARGB glyphs and pre-colour them. the end result will be slower
rendering that current software - that's my bet). so you are about as good as
it gets - acceleration-wise for "gtk" (2d). only thing that could be done is
some basic xrender accel (composite ARGB32 src to rgb565 dest if src and dest <
640x640). and that also involves having to have uploaded the ARGB32 pixel
source first - which is double the bandwidth needs of 16bit... across the bus
to the glamo (thus why i originally was so focused on trying to squeeze more
out of that bus - that is a real killer).

so right now other than bugs and trying to minimise cpu overhead on handling
the commandqueue 2d is done - it's not getting "faster". only thing left is 3d.
and that comes with a long list of gotchas. this is the bit where someone needs
to make a call on "what is the effort needed, and the result". this is up to
openmoko to decide what to do as the docs are in their hands. 2d is pretty much
done. :)

> >  $400 for a phone is a reasonable investment.  But months of work in
> > 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.
> Absolutely. I have already answered many aspects in other mails, but  
> let me summarize again:
> 
> 1. We currently are disappointed about s-media. To be fair to them I  
> do not want to quote from contracts we have with them, but let me tell  
> you at the bottom line we feel there have been some broken promises  
> with regards to opening documentation.
> 2. Because of this situation, we decided to not use s-media chips in  
> future Openmoko products.
> 3. At the same time, we decided to not come out with GTA02 versions  
> that had the glamo removed, because that would have been hard to do  
> technically, and it would have created too much technical fragmentation.
> 4. Even with raster's bashing, the glamo chip is a really nice mobile  

it's a professional opinion based on what i have seen in my years of doing
graphics. i think it's a very very weak graphics chip with lots of missing
holes in its featureset - given the kind of screen attached to it and the OS
and windowing system as well as the goals and desires of users. if you take the
OS and windowing system and goals as a given, the weak point is the glamo. a
spade is a spade. :) you can cover it with topping all you like. :)

> graphics chip. I say this also considering when it was released.  

ind

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

[Wolfgang Spraul]

Lally,

> how long is OM going to be using the Glamo?
The glamo will be kept for the lifetime of gta02, i.e. every gta02  
will have the glamo chip.
For gta03, release date unknown, the decision is to not have a glamo,  
we use the acceleration of the SoC.

>  The GTA02's been on the brink of obsolescence since the day it was  
> introduced.
Don't agree with you. In the long run everything is obsolete.
GTA02 is a real pioneering device for Linux in mobile phones, and is  
still advancing the state of Free Software in mobile phones in many  
areas.
We owe the community better hardware, and have made decisions  
internally to only focus on hardware and lower-level software.
But that will not remove the pioneering status of GTA02, not even when  
GTA03 ships, again release date unknown at this point.

> It can't even take most modern (3G) SIMs.
Thanks to great work from Dieter, Joerg and Werner, this bug (trac  
#666) seems to be fixed now, GSM reflash utility and instructions are  
available, etc.
Next they target trac #1024 (network re-registration).

> 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,
Long production life of GTA02.

>  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.
Very good idea. I always prefer breaking a large idea into smaller  
pieces.

>  $400 for a phone is a reasonable investment.  But months of work in
> 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.
Absolutely. I have already answered many aspects in other mails, but  
let me summarize again:

1. We currently are disappointed about s-media. To be fair to them I  
do not want to quote from contracts we have with them, but let me tell  
you at the bottom line we feel there have been some broken promises  
with regards to opening documentation.
2. Because of this situation, we decided to not use s-media chips in  
future Openmoko products.
3. At the same time, we decided to not come out with GTA02 versions  
that had the glamo removed, because that would have been hard to do  
technically, and it would have created too much technical fragmentation.
4. Even with raster's bashing, the glamo chip is a really nice mobile  
graphics chip. I say this also considering when it was released.  
Openmoko's speed of progress still does not match industry speed.  
While the other (closed) chip vendors are already 2 generations ahead,  
we (Openmoko and the Free Software community) are still writing  
drivers for older chips. But we shouldn't let others distract us. Our  
software is 100% Free Software. We want to be able to install mainline  
kernel.org kernels one day. We want to be able to run many Linux  
distributions on the phone one day. We are coming from behind, but I'm  
sure with the help of the community we can even drag something like  
the glamo out into the open.
5. We will have the same problem with open 2D/3D acceleration again in  
the future, so breaking the glamo free could be considered a good  
'exercise'. No matter whether you look at future Samsung, TI, Marvell  
chips. The 3D acceleration part is always closed. In other words needs  
to be opened by us. We might as well start with the glamo now, better  
than waiting for the 'perfect moment' which will never come...

Best Regards,
Wolfgang

On Nov 17, 2008, at 3:40 PM, Lally Singh wrote:

> 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.
>
>  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.
>
>  $400 for a phone is a reasonable investme

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

[The Rasterman]

On Fri, 21 Nov 2008 04:11:58 +0100 Sascha Wessel <[EMAIL PROTECTED]> babbled:

> Hi,
> 
> 
> On Fri, Nov 21, 2008 at 12:28:44PM +1100, Carsten Haitzler wrote:
> > the policy of the kernel developers is not to export interrupts to
> > usersapce in a generic way - or it hasn't been in the past. this may have
> > changed recently. so u can patch and create a specific driver just for
> > glamo just to export an interrupt - and it'll never go upstream most
> > likely, and the kernel supports no "generic" hook to an interrupt from
> > userspace. one way or another something will block your path (be it getting
> > patches upstream back to mainline kernel or just living without interrupts
> > etc.). this is last i checked. 
> 
> I have never tried it but userspace i/o [1] is a more or less generic
> way to export interrupts to userspace (in the kernel since ~2.6.23).

this is relatively new. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Sascha Wessel]

Hi,


On Fri, Nov 21, 2008 at 12:28:44PM +1100, Carsten Haitzler wrote:
> the policy of the kernel developers is not to export interrupts to usersapce 
> in
> a generic way - or it hasn't been in the past. this may have changed recently.
> so u can patch and create a specific driver just for glamo just to export an
> interrupt - and it'll never go upstream most likely, and the kernel supports
> no "generic" hook to an interrupt from userspace. one way or another something
> will block your path (be it getting patches upstream back to mainline kernel 
> or
> just living without interrupts etc.). this is last i checked. 

I have never tried it but userspace i/o [1] is a more or less generic
way to export interrupts to userspace (in the kernel since ~2.6.23).


Greetings,
Sascha


[1] http://www.kernel.org/doc/htmldocs/uio-howto/


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[The Rasterman]

On Fri, 21 Nov 2008 02:18:25 +0100 Sascha Wessel <[EMAIL PROTECTED]> babbled:

> Hi,
> 
> On Fri, Nov 21, 2008 at 09:16:15AM +1100, Carsten Haitzler wrote:
> > On Thu, 20 Nov 2008 19:00:02 +0100 "Nicola Mfb" <[EMAIL PROTECTED]>
> > babbled:
> > > I wrote a small code snippet to test XCopyArea performance, and it seems
> > > to do about 25fps smoothscrolling but at the cost of XGlamo using 70/80%
> > > of CPU. This seems very strange, it maybe my code is wrong (I repeat I'm
> > > not an expert :) ), or XCopyArea is not full accelerated, or Xglamo has
> > > to be optimized, or that the Glamo GPU is simply slow :)
> > 
> > it's accelerated - but likely polling the command queue status as you have
> > no interrupts thanks to the linux kernel's policy of not exporting
> > interrupts to userspace, so you're stuck with a poll loop. i can't remember
> > if glamo had a "i'm done" interrupt for the command queue or operations - i
> > know it had several interrupts it can generate (but as the kernel wouldnt
> > allow userspace to make use of them i pretty much ignored them).
> 
> ???
> 
> What's wrong with: interrupt handler -> wait queue -> file operations
> read/poll?

the policy of the kernel developers is not to export interrupts to usersapce in
a generic way - or it hasn't been in the past. this may have changed recently.
so u can patch and create a specific driver just for glamo just to export an
interrupt - and it'll never go upstream most likely, and the kernel supports
no "generic" hook to an interrupt from userspace. one way or another something
will block your path (be it getting patches upstream back to mainline kernel or
just living without interrupts etc.). this is last i checked. 

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Sascha Wessel]

Hi,

On Fri, Nov 21, 2008 at 09:16:15AM +1100, Carsten Haitzler wrote:
> On Thu, 20 Nov 2008 19:00:02 +0100 "Nicola Mfb" <[EMAIL PROTECTED]> babbled:
> > I wrote a small code snippet to test XCopyArea performance, and it seems to
> > do about 25fps smoothscrolling but at the cost of XGlamo using 70/80% of
> > CPU. This seems very strange, it maybe my code is wrong (I repeat I'm not an
> > expert :) ), or XCopyArea is not full accelerated, or Xglamo has to be
> > optimized, or that the Glamo GPU is simply slow :)
> 
> it's accelerated - but likely polling the command queue status as you have no
> interrupts thanks to the linux kernel's policy of not exporting interrupts to
> userspace, so you're stuck with a poll loop. i can't remember if glamo had a
> "i'm done" interrupt for the command queue or operations - i know it had
> several interrupts it can generate (but as the kernel wouldnt allow userspace
> to make use of them i pretty much ignored them).

???

What's wrong with: interrupt handler -> wait queue -> file operations read/poll?


Greetings,
Sascha


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[The Rasterman]

On Thu, 20 Nov 2008 19:00:02 +0100 "Nicola Mfb" <[EMAIL PROTECTED]> babbled:

> 2008/11/18 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>
> 
> > [...]
> > evas supports opengl too. no it doesn't have an advantage, as glamo won't
> > be
> > doing opengl at VGA (the resolution of the device) so you won't be doing it
> > for
> > normal 2D UI's (thus my comments of it being of limited use for some
> > fullscreen
> > games for example where you drop to QVGA for the game). also the 256x256
> > max
> > texture size leads to problems even if it could do VGA output.
> 
> 
> Oh this is a definitive limit, I would appreciate 3d acceleration to speedup
> everyday apps, and not some small 3d games, this is secondary for the
> freerunner actually.
> 
> 
> > > *) when necessary you can use directly Xlib because X is 2d accelerated ?
> >
> > you ALWAYS use xlib* - if you want to interact with x in any way.
> 
> 
> I mean, if my preferred toolkit does not advantages of hardware
> acceleration, I may use Xlib and call for example XCopyArea to do fast blits
> in video memory?

you can.

> I wrote a small code snippet to test XCopyArea performance, and it seems to
> do about 25fps smoothscrolling but at the cost of XGlamo using 70/80% of
> CPU. This seems very strange, it maybe my code is wrong (I repeat I'm not an
> expert :) ), or XCopyArea is not full accelerated, or Xglamo has to be
> optimized, or that the Glamo GPU is simply slow :)

it's accelerated - but likely polling the command queue status as you have no
interrupts thanks to the linux kernel's policy of not exporting interrupts to
userspace, so you're stuck with a poll loop. i can't remember if glamo had a
"i'm done" interrupt for the command queue or operations - i know it had
several interrupts it can generate (but as the kernel wouldnt allow userspace
to make use of them i pretty much ignored them).

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Nicola Mfb]

2008/11/18 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>

> [...]
> evas supports opengl too. no it doesn't have an advantage, as glamo won't
> be
> doing opengl at VGA (the resolution of the device) so you won't be doing it
> for
> normal 2D UI's (thus my comments of it being of limited use for some
> fullscreen
> games for example where you drop to QVGA for the game). also the 256x256
> max
> texture size leads to problems even if it could do VGA output.


Oh this is a definitive limit, I would appreciate 3d acceleration to speedup
everyday apps, and not some small 3d games, this is secondary for the
freerunner actually.


> > *) when necessary you can use directly Xlib because X is 2d accelerated ?
>
> you ALWAYS use xlib* - if you want to interact with x in any way.


I mean, if my preferred toolkit does not advantages of hardware
acceleration, I may use Xlib and call for example XCopyArea to do fast blits
in video memory?
I wrote a small code snippet to test XCopyArea performance, and it seems to
do about 25fps smoothscrolling but at the cost of XGlamo using 70/80% of
CPU. This seems very strange, it maybe my code is wrong (I repeat I'm not an
expert :) ), or XCopyArea is not full accelerated, or Xglamo has to be
optimized, or that the Glamo GPU is simply slow :)

Regards

 Nicola
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Iain B. Findleton]

For those of you who are interested in the fltkwish package for the FR,
I have added a couple of ipk packages to the SF repository. The fb2image
package is a small screen shot utility that is capable of generating
either png or jpg images from a sub-window of the FR screen. The
fltkwishlibs package contains the pre-built Tcl 8.4, Mesa 7.03 (OpenGL,
GLU) and TIFF 3.0 libs. All of this is installed under the /usr/local
path, which I have on my SD card to save space on the FR itself.

The sources for these libs are widely available on the net, and the
binaries are just builds of the unmodified sources using the ARM tool chain.

Have fun. Send complaints to my regular e-mail.

Iain F.

Iain B. Findleton wrote:
> Okay, for those of you who would like to test out this thing on your FR,
> you can get an ipk from the fltkwish project on sourceforge.net. Once
> you have Tcl on your phone (opkg install tcl), and the required
> graphics libraries, you can do a quick test with the following script:
>
> #!/bin/sh
> # \
> exec fltkwish "$0" ${1+"$@"}
> #
> # Create an Image widget and load up a file
> #
> Image t.t -f myfile.jpg -w 460 -h 570 -autoscale false -center false;
>
> Show t
>
> You can now drag the image about with your finger, or pen. On my machine
> the dragging is nice and smooth. You should have an image that is bigger
> than the display screen to fully appreciate the results.
>
> If you have troubles, and if you have read the documentation and still
> have troubles, feel free to contact me.
>
> Iain F.
>
>
>
> Petr Vanek wrote:
>   
>> On Tue, 18 Nov 2008 10:58:41 -0500
>> "Iain B. Findleton"
>> <[EMAIL PROTECTED]> (IBF) wrote:
>>
>>   
>> 
>>> No problem, although my setup is not opkg ready yet. As my stuff uses
>>> Tcl, libjpeg,libpng,libtiff, the setup is not pretty yet, but if you
>>> are a Linux handyman type, it can be done. Otherwise, it will have to
>>> wait until I get around to package it all up...
>>> 
>>>   
>> Yes please, do share anyways,
>>
>> thank you
>>
>> Petr
>>
>>
>>
>> ___
>> Openmoko community mailing list
>> community@lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>>   
>> 
>
>
>   


-- 
Iain B. Findleton
Tel: 514-457-0744


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[The Rasterman]

On Tue, 18 Nov 2008 15:01:51 +0100 "Nicola Mfb" <[EMAIL PROTECTED]> babbled:

> 2008/11/17 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>
> 
> > [...]
> 
> no - it's not possible to do a "scroll" (via blit) as you have
> > alpha channels, layered objects etc. etc. - just trust me in that the cost
> > of
> > trying to figure out a blit - if it is possible is probably much higher
> > than
> > the cost of just doing a redraw in almost all cases - the upload speed of
> > the
> > glamo is so low though that it may just be worth it...
> 
> 
> I understand and trust your huge experience :), so correct me where wrong,
> I'm not expert but I'd like to have an high level view on this:
> 
> *) standard toolkit do complex operation so it's simple/better recompute and
> upload the view, this means that porting existing software based on them may
> result in slow performance.

it depends. its a tradeoff of flexibility and power to change the look and feel
of things vs cost.

> *) toolkits that advantages of OpenGL to accelerate its widgets (for example
> Qt let you choose an opengl viewport for their canvas implementation)  does
> not advantage as Glamo has only 2d acceleration.

evas supports opengl too. no it doesn't have an advantage, as glamo won't be
doing opengl at VGA (the resolution of the device) so you won't be doing it for
normal 2D UI's (thus my comments of it being of limited use for some fullscreen
games for example where you drop to QVGA for the game). also the 256x256 max
texture size leads to problems even if it could do VGA output. you'd need to
now do texture meshes - and these are nasty if you want scaling to work right
(with interpolation and/or mipmaps, anisotropic filtering etc. etc. - in the
more general case).

> *) when necessary you can use directly Xlib because X is 2d accelerated ?

you ALWAYS use xlib* - if you want to interact with x in any way.

(* or xcb... or write your own x protocol but same - both are x protocol wrapper
libraries.)

> *) when necessary you may use lowlevel library/toolkit to bypass X overhead
> and use accelerated 2d graphics (sdl?) ?

sdl offers screen setup - not acceleration (really - ok for some specific
things it wraps that too - but not in general). sdl USES x. same as anyone else
(i am ignoring using sdl on the framebuffer - that's no different to using the
fb directly).

> *) about video streams, bandwidth is not an issue if decoding mpeg4 in
> glamo, but is a issue if you decode the stream with the main CPU and upload
> the frames to the glamo?

yes. it's an issue in this case. decoding mpeg4 on glamo is problematic due to
audio not being decoded on the glamo and having to synchronise. all uploads to
video block the cpu so you have no cycles to decode the next frame while
uploading the current one (slowly). same with ANY pixel uploads.

> *) glamo will be abandoned, the cost to develop a 3d driver is very high,
> what's about completing 2d acceleration and mpeg4 hardware decoding?

imho it'd dubiously useful - sure. it works. the audio issues, synchronisation,
there being no standard x extension/mechanism to upload codec data (having to
invent one - this is though a very worthy idea) etc.

> *) the community may produce now or at later time the wanted 3d driver, but
> this is hard as openmoko has to extend the nda in some legal way

om can't. unless you work for om. smedia control the nda - not om.

> Regards
> 
> Nicola
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Iain B. Findleton]

Okay, for those of you who would like to test out this thing on your FR,
you can get an ipk from the fltkwish project on sourceforge.net. Once
you have Tcl on your phone (opkg install tcl), and the required
graphics libraries, you can do a quick test with the following script:

#!/bin/sh
# \
exec fltkwish "$0" ${1+"$@"}
#
# Create an Image widget and load up a file
#
Image t.t -f myfile.jpg -w 460 -h 570 -autoscale false -center false;

Show t

You can now drag the image about with your finger, or pen. On my machine
the dragging is nice and smooth. You should have an image that is bigger
than the display screen to fully appreciate the results.

If you have troubles, and if you have read the documentation and still
have troubles, feel free to contact me.

Iain F.



Petr Vanek wrote:
> On Tue, 18 Nov 2008 10:58:41 -0500
> "Iain B. Findleton"
> <[EMAIL PROTECTED]> (IBF) wrote:
>
>   
>> No problem, although my setup is not opkg ready yet. As my stuff uses
>> Tcl, libjpeg,libpng,libtiff, the setup is not pretty yet, but if you
>> are a Linux handyman type, it can be done. Otherwise, it will have to
>> wait until I get around to package it all up...
>> 
>
> Yes please, do share anyways,
>
> thank you
>
> Petr
>
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>   


-- 
Iain B. Findleton
Tel: 514-457-0744


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Petr Vanek]

On Tue, 18 Nov 2008 10:58:41 -0500
"Iain B. Findleton"
<[EMAIL PROTECTED]> (IBF) wrote:

>No problem, although my setup is not opkg ready yet. As my stuff uses
>Tcl, libjpeg,libpng,libtiff, the setup is not pretty yet, but if you
>are a Linux handyman type, it can be done. Otherwise, it will have to
>wait until I get around to package it all up...

Yes please, do share anyways,

thank you

Petr



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Iain B. Findleton]

No problem, although my setup is not opkg ready yet. As my stuff uses
Tcl, libjpeg,libpng,libtiff, the setup is not pretty yet, but if you are
a Linux handyman type, it can be done. Otherwise, it will have to wait
until I get around to package it all up...

Nicola Mfb wrote:
> 2008/11/17 Iain B. Findleton <[EMAIL PROTECTED]
> >
>
> I have implemented an image display script on the FR that demonstrates
> smooth scroll in the form of dragging the image about the screen.
> Works
> for fairly large images (colour weather maps of North America). The
> application uses the FLTK tool kit with double buffering through X.
>
>
> May you share it?
>
> Thanks
>  
> Nicola
> 
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>   


-- 
Iain B. Findleton
Tel: 514-457-0744


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Nicola Mfb]

2008/11/17 Iain B. Findleton <[EMAIL PROTECTED]>

> I have implemented an image display script on the FR that demonstrates
> smooth scroll in the form of dragging the image about the screen. Works
> for fairly large images (colour weather maps of North America). The
> application uses the FLTK tool kit with double buffering through X.
>

May you share it?

Thanks

Nicola
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Nicola Mfb]

2008/11/17 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>

> [...]

no - it's not possible to do a "scroll" (via blit) as you have
> alpha channels, layered objects etc. etc. - just trust me in that the cost
> of
> trying to figure out a blit - if it is possible is probably much higher
> than
> the cost of just doing a redraw in almost all cases - the upload speed of
> the
> glamo is so low though that it may just be worth it...


I understand and trust your huge experience :), so correct me where wrong,
I'm not expert but I'd like to have an high level view on this:

*) standard toolkit do complex operation so it's simple/better recompute and
upload the view, this means that porting existing software based on them may
result in slow performance.
*) toolkits that advantages of OpenGL to accelerate its widgets (for example
Qt let you choose an opengl viewport for their canvas implementation)  does
not advantage as Glamo has only 2d acceleration.
*) when necessary you can use directly Xlib because X is 2d accelerated ?
*) when necessary you may use lowlevel library/toolkit to bypass X overhead
and use accelerated 2d graphics (sdl?) ?
*) about video streams, bandwidth is not an issue if decoding mpeg4 in
glamo, but is a issue if you decode the stream with the main CPU and upload
the frames to the glamo?
*) glamo will be abandoned, the cost to develop a 3d driver is very high,
what's about completing 2d acceleration and mpeg4 hardware decoding?
*) the community may produce now or at later time the wanted 3d driver, but
this is hard as openmoko has to extend the nda in some legal way

Regards

Nicola
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Jacob Peterson]

On Mon, Nov 17, 2008 at 6:12 PM, Aliner <[EMAIL PROTECTED]> wrote:

> On Mon, Nov 17, 2008 at 12:06 PM, Graeme Gregory <[EMAIL PROTECTED]>wrote:
>
>> On Mon, 2008-11-17 at 11:58 -0500, Aliner wrote:
>> > If we work on having x.org server working on the FR, wouldn't that
>> > help for whatever comes next?. At least we would have some working
>> > knowledge on how to develop drivers for X, and a team of programmers
>> > with ample knowledge on all things regarding the x.org Server.
>> >
>> > I mean, the thing is modularized. Is it not simpler to just replace
>> > the glamo driver with the [whatever\] driver?
>> >
>>
>> Basically yes, the advantages of Xorg are active development and
>> familiarity with developers as comapred to kdrive based stuff.
>>
>> At the moment Xorg with tslib/fbdev drivers works well on GTA02
>> my task now is to make a glamo driver for Xorg based on the Xglamo
>> code.
>
>
> Do you have the instructions to build Xorg with the toolchain?
>
>>
>> Graeme
>>
>>
>>
>>
>> ___
>> Openmoko community mailing list
>> community@lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>>
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>
I thought Debian on the FR started with X by default?  Testing that would
give you a quick comparison if you didn't feel like building X.  Also,
kdrive is part of Xorg now, so you just simply pass it the --enable-kdrive
flag at compile time according to information at freedesktop.org [1].

-Jacob

[1] http://www.freedesktop.org/wiki/Software/Xserver
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Graeme Gregory]

On Mon, 2008-11-17 at 12:12 -0500, Aliner wrote:
> On Mon, Nov 17, 2008 at 12:06 PM, Graeme Gregory <[EMAIL PROTECTED]>
> wrote:
> On Mon, 2008-11-17 at 11:58 -0500, Aliner wrote:
> > If we work on having x.org server working on the FR,
> wouldn't that
> > help for whatever comes next?. At least we would have some
> working
> > knowledge on how to develop drivers for X, and a team of
> programmers
> > with ample knowledge on all things regarding the x.org
> Server.
> >
> > I mean, the thing is modularized. Is it not simpler to just
> replace
> > the glamo driver with the [whatever\] driver?
> >
> 
> 
> Basically yes, the advantages of Xorg are active development
> and
> familiarity with developers as comapred to kdrive based stuff.
> 
> At the moment Xorg with tslib/fbdev drivers works well on
> GTA02
> my task now is to make a glamo driver for Xorg based on the
> Xglamo
> code.
> 
> Do you have the instructions to build Xorg with the toolchain?

No, Im an OE guy so I use OE as my toolchain.

Graeme




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Aliner]

On Mon, Nov 17, 2008 at 12:06 PM, Graeme Gregory <[EMAIL PROTECTED]>wrote:

> On Mon, 2008-11-17 at 11:58 -0500, Aliner wrote:
> > If we work on having x.org server working on the FR, wouldn't that
> > help for whatever comes next?. At least we would have some working
> > knowledge on how to develop drivers for X, and a team of programmers
> > with ample knowledge on all things regarding the x.org Server.
> >
> > I mean, the thing is modularized. Is it not simpler to just replace
> > the glamo driver with the [whatever\] driver?
> >
>
> Basically yes, the advantages of Xorg are active development and
> familiarity with developers as comapred to kdrive based stuff.
>
> At the moment Xorg with tslib/fbdev drivers works well on GTA02
> my task now is to make a glamo driver for Xorg based on the Xglamo
> code.


Do you have the instructions to build Xorg with the toolchain?

>
> Graeme
>
>
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Graeme Gregory]

On Mon, 2008-11-17 at 11:58 -0500, Aliner wrote:
> If we work on having x.org server working on the FR, wouldn't that
> help for whatever comes next?. At least we would have some working
> knowledge on how to develop drivers for X, and a team of programmers
> with ample knowledge on all things regarding the x.org Server.
> 
> I mean, the thing is modularized. Is it not simpler to just replace
> the glamo driver with the [whatever\] driver?
> 

Basically yes, the advantages of Xorg are active development and
familiarity with developers as comapred to kdrive based stuff.

At the moment Xorg with tslib/fbdev drivers works well on GTA02
my task now is to make a glamo driver for Xorg based on the Xglamo
code.

Graeme




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Aliner]

If we work on having x.org server working on the FR, wouldn't that help for
whatever comes next?. At least we would have some working knowledge on how
to develop drivers for X, and a team of programmers with ample knowledge on
all things regarding the x.org Server.

I mean, the thing is modularized. Is it not simpler to just replace the
glamo driver with the [whatever\] driver?

On Mon, Nov 17, 2008 at 11:48 AM, Iain B. Findleton <[EMAIL PROTECTED]
> wrote:

> I have implemented an image display script on the FR that demonstrates
> smooth scroll in the form of dragging the image about the screen. Works
> for fairly large images (colour weather maps of North America). The
> application uses the FLTK tool kit with double buffering through X.
>
>
>
> Nicola Mfb wrote:
> > 2008/11/17 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]
> > >
> >
> > [...]
> >
> > 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.
> >
> >
> > Hi Raster! before reading this post I supposed that 2d acceleration
> > was very partially implemented. This cames out for example because I
> > never see a smooth scroll on the device. So what is the reason for
> > this? glamo? 2d acceleration driver? poor graphics toolkit?
> >
> > Regards
> >
> > Nicola
> >
> >
> >
> > 
> >
> > ___
> > Openmoko community mailing list
> > community@lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >
>
>
> --
> Iain B. Findleton
> Tel: 514-457-0744
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Iain B. Findleton]

I have implemented an image display script on the FR that demonstrates
smooth scroll in the form of dragging the image about the screen. Works
for fairly large images (colour weather maps of North America). The
application uses the FLTK tool kit with double buffering through X.



Nicola Mfb wrote:
> 2008/11/17 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]
> >
>
> [...]
>
> 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.
>
>
> Hi Raster! before reading this post I supposed that 2d acceleration
> was very partially implemented. This cames out for example because I
> never see a smooth scroll on the device. So what is the reason for
> this? glamo? 2d acceleration driver? poor graphics toolkit?
>
> Regards
>
> Nicola
>
>
>
> 
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>   


-- 
Iain B. Findleton
Tel: 514-457-0744


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Leonti Bielski]

Personally I don't think we should spend a lot of precious time on glamo.
It's working now reasonably well - Rasterman's illume looks good - it
has effects and it's not to slow.
 The reason why in my opinion openmoko shouldn't spend time on this is
simple - it has a lot more important tasks to do.
This is the same reason I think openmoko shouldn't work on ASU - it's
going to be obsolete, so why waste time and money?
Of course if someone has spare time and is willing to work on this -
it's great, but I think we have to sacrifice some things to speed up
development of future devices.

Leonti

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[The Rasterman]

On Mon, 17 Nov 2008 14:30:31 +0100 "Nicola Mfb" <[EMAIL PROTECTED]> babbled:

>
> Hi Raster! before reading this post I supposed that 2d acceleration was very
> partially implemented. This cames out for example because I never see a
> smooth scroll on the device. So what is the reason for this? glamo? 2d
> acceleration driver? poor graphics toolkit?

depends on the toolkit and how ti does it. efl doesn't use any "blitting" at all
for scrolling. it's a redraw - thus a re-compute of pixels and write to screen.
i won't go into the details why - but they are complex. glamo can't do enough
to cover the accelerated paths (xrender for example) so you get s a software
re-compute. no - it's not possible to do a "scroll" (via blit) as you have
alpha channels, layered objects etc. etc. - just trust me in that the cost of
trying to figure out a blit - if it is possible is probably much higher than
the cost of just doing a redraw in almost all cases - the upload speed of the
glamo is so low though that it may just be worth it... but i don't intend to
bother as the glamo on the freerunner is a complete anomaly in terms of
performance and i  have other much better and more important platforms to
support as well :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Nicola Mfb]

2008/11/17 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>

> [...]
> 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.
>

Hi Raster! before reading this post I supposed that 2d acceleration was very
partially implemented. This cames out for example because I never see a
smooth scroll on the device. So what is the reason for this? glamo? 2d
acceleration driver? poor graphics toolkit?

Regards

Nicola
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Jacob Peterson]

On Mon, Nov 17, 2008 at 11:52 AM, Timo Jyrinki <[EMAIL PROTECTED]>wrote:

> 2008/11/17 Lally Singh <[EMAIL PROTECTED]>:
> >  $400 for a phone is a reasonable investment.  But months of work in
> > 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.
>
> Hey people, please don't underestimate the general willingness to hack
> stuff :) Most of us don't think about value-for-money, sensibility or
> other minor aspects. Coding is fun! That's why we have
> accelerometer-controlled Doom working fluently before phone calls, and
> I think it's great ;)
>
> So I don't think there's any value discussing how sensible /
> meaningful / valuable doing OpenGL support would be. If there are
> people interested, that's great and it's not cutting anything away
> from somewhere else. Volunteer people need to do what they like to do,
> not what's the most sensible product-wise.
>
> And we already have eg. partial MPEG4 hw decoding using Glamo, imagine
> if the developer of that would have been told "don't waste your time
> on something like that".
>
> -Timo
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>


Timo you have hit it right on, what is being asked is not for Openmoko to do
the work, but trying to organize a community effort to bring these features
to the phone.  Which involves a few hurtles to be crossed first due to the
NDA'ed documentation, however Openmoko seems to be very willing to help any
effort which enables the community to work on this.

In my ideal little world, I would love to first just see OpenGL ES support
added to the existing driver as soon as possible.  That way everyone can
benefit and start playing with OpenGL applications right away, then in the
long term start a project to rewrite the driver around X.

-Jacob
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Charles Pax]

On Mon, Nov 17, 2008 at 5:52 AM, Timo Jyrinki <[EMAIL PROTECTED]>wrote:

> Coding is fun! That's why we have
> accelerometer-controlled Doom working fluently before phone calls, and
> I think it's great ;)
>

I'm just starting my day here on the East coast of the U.S.. I'm confident
what you just wrote will be the funniest thing I encounter all day.

-Charles Pax
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| On Sun, Nov 16, 2008 at 4:34 PM, Andy Green <[EMAIL PROTECTED]> wrote:
|> FWIW I talked this over with an experienced 3D guy recently about
|> something related and he was all in favour of discarding the kdrive
|> implementation and making a pure xorg one as a way forward: he told that
|> kdrive itself was long dead.  I also know that XGlamo is not that great

| Just fair warning here.  As I don't think OM will use the Glamo in
| future devices, doing the "right thing" isn't as critical as normal
| software projects.  Spend the energy making the best performing, most
| functional implementation possible.  If that goal's met, *then* go
| back and shove it into Xorg.

We don't plan to use Glamo at the moment, but we do seem to be planning
and are working twoards using xorg everywhere.  It makes sense to have a
consistent strategy for it across all the devices using the best solution.

More developers are likely to want to expend effort to get experience
with xorg / GLX type solution than known-deprecated kdrive / lashup
implementation.

If you look at GTA01 experience, that is still a living device running
current rootfs, we can expect GTA02 to have similar long life, we should
also make architectural decisions with that in mind I think.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkhT3MACgkQOjLpvpq7dMp8BACffuMTO4LWmoPpsIkqKoI4cCIO
35gAoICe9V8TsLesAtddradgxsOsrdsY
=H9Ot
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Timo Jyrinki]

2008/11/17 Lally Singh <[EMAIL PROTECTED]>:
>  $400 for a phone is a reasonable investment.  But months of work in
> 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.

Hey people, please don't underestimate the general willingness to hack
stuff :) Most of us don't think about value-for-money, sensibility or
other minor aspects. Coding is fun! That's why we have
accelerometer-controlled Doom working fluently before phone calls, and
I think it's great ;)

So I don't think there's any value discussing how sensible /
meaningful / valuable doing OpenGL support would be. If there are
people interested, that's great and it's not cutting anything away
from somewhere else. Volunteer people need to do what they like to do,
not what's the most sensible product-wise.

And we already have eg. partial MPEG4 hw decoding using Glamo, imagine
if the developer of that would have been told "don't waste your time
on something like that".

-Timo

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Jacob Peterson]

The idea, as it stands now, is for a community led effort to implement
OpenGL ES support for the Glamo.  There was also mention of trying to assist
a clean room documentation project so the documents can be out in the
community for people to do with as the please, and later if enough people
are motivated maybe a entirely new implementation of the driver could be
created.  I think the focus for a community led team should be simply on
getting OpenGL ES support in the driver and documentation available.  This
leaves Openmoko staff to focus on more important issues.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[The Rasterman]

On Mon, 17 Nov 2008 02:40:19 -0500 "Lally Singh" <[EMAIL PROTECTED]>
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

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

[Lally Singh]

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.

  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.

  $400 for a phone is a reasonable investment.  But months of work in
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.

-ls

On Sun, Nov 16, 2008 at 11:43 PM, Neng-Yu Tu (Tony Tu)
<[EMAIL PROTECTED]> 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@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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Neng-Yu Tu (Tony Tu)]

-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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Nicola Mfb]

2008/11/17 Gothnet <[EMAIL PROTECTED]>

>
>
> If OM drop efforts to make 02 better, then they'll probably have a lot of
> folks that just won't buy the 03 because they're angry.
>

About freerunner in general if Openmoko will drop effort on it they'll have
to ship a gta03 without issues otherwise peoples will not trust them anymore
:). About the glamo, did someone evaulate how much it will cost to produce
the wanted 3d driver, and how much *customers* will be happy of this?

Regards

Nicola
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Lally Singh]

On Sun, Nov 16, 2008 at 7:42 PM, Gothnet <[EMAIL PROTECTED]> wrote:
> Lally Singh wrote:
>> Just fair warning here.  As I don't think OM will use the Glamo in
>> future devices, doing the "right thing" isn't as critical as normal
>> software projects...
> Doing the right this IS critical to support the freerunner, going forward.
> I, personally, get rather worried by all this talk of supporting future
> revisions and not putting in too much freerunner-specific energy because "it
> won't be loing until GTA03 is here"
>
> If OM drop efforts to make 02 better, then they'll probably have a lot of
> folks that just won't buy the 03 because they're angry.

I think the FR needs an accelerator going forward, but I doubt it's the Glamo.

More importantly, I think there's a lot of potential fun to be had with this:
http://www.clutter-project.org/

-ls

-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Gothnet]

Lally Singh wrote:
> 
> 
> Just fair warning here.  As I don't think OM will use the Glamo in
> future devices, doing the "right thing" isn't as critical as normal
> software projects...
> 
> -- 
> H. Lally Singh
> Ph.D. Candidate, Computer Science
> Virginia Tech
> 
> 

Doing the right this IS critical to support the freerunner, going forward.
I, personally, get rather worried by all this talk of supporting future
revisions and not putting in too much freerunner-specific energy because "it
won't be loing until GTA03 is here"

If OM drop efforts to make 02 better, then they'll probably have a lot of
folks that just won't buy the 03 because they're angry.
-- 
View this message in context: 
http://n2.nabble.com/Calling-interested-Glamo-OpenGL-developers-%28was%3A-The-forbidden-topic%3A-Glamo-OpenGL%29-tp1505667p1507674.html
Sent from the Openmoko Community mailing list archive at Nabble.com.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Lally Singh]

On Sun, Nov 16, 2008 at 4:34 PM, Andy Green <[EMAIL PROTECTED]> wrote:
> FWIW I talked this over with an experienced 3D guy recently about
> something related and he was all in favour of discarding the kdrive
> implementation and making a pure xorg one as a way forward: he told that
> kdrive itself was long dead.  I also know that XGlamo is not that great
> a solution since it is largely the Linux framebuffer driver basically
> cut and pasted into userspace with the locking not being shared between
> kernel and userland.  Whatever it's replaced with ought to be glued into
> kernel Glamo framebuffer driver I think at the very least for any
> critical shared parts like locking and this modal commandqueue stuff.
>
> He also said the same that Glamo was ES, I think 1.1.  Since Graeme is
> going ahead with xorg generally it sounds like this is the recommended
> path to follow if at all possible.
>
> Lastly he mentioned 2442 has no float unit so this impacts the
> implementation, but apparently it's not a killer to used fixed in ES.


Just fair warning here.  As I don't think OM will use the Glamo in
future devices, doing the "right thing" isn't as critical as normal
software projects.  Spend the energy making the best performing, most
functional implementation possible.  If that goal's met, *then* go
back and shove it into Xorg.


-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| I have some questions, the glamo chip contains 3d support, what
| version of OpenGL (or OpenGL ES) is implemented?
| Are we still going to keep Xglamo (kdrive) or are we goint to use
| X.org server? (this question arised after Rastermans e-mail)

| 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.

FWIW I talked this over with an experienced 3D guy recently about
something related and he was all in favour of discarding the kdrive
implementation and making a pure xorg one as a way forward: he told that
kdrive itself was long dead.  I also know that XGlamo is not that great
a solution since it is largely the Linux framebuffer driver basically
cut and pasted into userspace with the locking not being shared between
kernel and userland.  Whatever it's replaced with ought to be glued into
kernel Glamo framebuffer driver I think at the very least for any
critical shared parts like locking and this modal commandqueue stuff.

He also said the same that Glamo was ES, I think 1.1.  Since Graeme is
going ahead with xorg generally it sounds like this is the recommended
path to follow if at all possible.

Lastly he mentioned 2442 has no float unit so this impacts the
implementation, but apparently it's not a killer to used fixed in ES.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkgkdUACgkQOjLpvpq7dMr+kgCfcJFz7F2qCJWXtB+63c0scJ5x
Yq0An1dfewn2MdpYXxPwl1T73kgegoTd
=0qfk
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[RzR www.rzr.online.fr]

What about using a software opengl es implementation ?
I used to play on this on wince targets (using vincent)

Anyway that's a job I'd like to be involved in , if I had time to
-- 
Related Obsession : http://rzr.online.fr/q/OpenGlEs

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Jacob Peterson]

On Sun, Nov 16, 2008 at 8:49 PM, Aliner <[EMAIL PROTECTED]> wrote:

> You can count me in. I have experience doing kernel development. Since the
> documentation is not available, I saw a couple of pointers on how to start
> on the nouveau project. They have an excellent section on tools and
> documentation. http://nouveau.freedesktoplorg/wiki.
>
> I have some questions, the glamo chip contains 3d support, what version of
> OpenGL (or OpenGL ES) is implemented?
> Are we still going to keep Xglamo (kdrive) or are we goint to use X.org
> server? (this question arised after Rastermans e-mail)
> Are we going to support full OpenGL or OpenGL ES on the implementation?
> Or is it going to be a OpenGL driver and a OpenGL ES driver?
>
> Thank you


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.

-Jacob
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Aliner]

You can count me in. I have experience doing kernel development. Since the
documentation is not available, I saw a couple of pointers on how to start
on the nouveau project. They have an excellent section on tools and
documentation. http://nouveau.freedesktoplorg/wiki.

I have some questions, the glamo chip contains 3d support, what version of
OpenGL (or OpenGL ES) is implemented?
Are we still going to keep Xglamo (kdrive) or are we goint to use X.org
server? (this question arised after Rastermans e-mail)
Are we going to support full OpenGL or OpenGL ES on the implementation?
Or is it going to be a OpenGL driver and a OpenGL ES driver?

Thank you

On Sun, Nov 16, 2008 at 2:11 PM, "Marco Trevisan (Treviño)"
<[EMAIL PROTECTED]>wrote:

> Jacob Peterson wrote:
> > There has been some discussion on the recently about the Glamo and
> > OpenGL where Wolfgang called for serious developers to get in touch with
> > him and he would see what could be done about getting access to the
> > NDA'ed Glamo documents [1].  A couple of developers responded saying
> > they were interested.  I would like to see how many people are
> > interested and willing to commit to working on and OpenGL driver in this
> > thread.  If there is enough interest I will start a project one
> > projects.openmoko.org  and then we can
> > work with Openmoko on the legal aspects of the NDA.
> >
> > So please, if you are interested and motivated lets discuss it here,
> > then we can work on getting the rest in motion.
>
> What about cross-posting this also to mesa-devel and dri-devel?
>
> --
> Treviño's World - Life and Linux
> http://www.3v1n0.net/
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Marco Trevisan (Treviño)]

Jacob Peterson wrote:
> There has been some discussion on the recently about the Glamo and
> OpenGL where Wolfgang called for serious developers to get in touch with
> him and he would see what could be done about getting access to the
> NDA'ed Glamo documents [1].  A couple of developers responded saying
> they were interested.  I would like to see how many people are
> interested and willing to commit to working on and OpenGL driver in this
> thread.  If there is enough interest I will start a project one
> projects.openmoko.org  and then we can
> work with Openmoko on the legal aspects of the NDA.
> 
> So please, if you are interested and motivated lets discuss it here,
> then we can work on getting the rest in motion.

What about cross-posting this also to mesa-devel and dri-devel?

-- 
Treviño's World - Life and Linux
http://www.3v1n0.net/


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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

[Jacob Peterson]

There has been some discussion on the recently about the Glamo and OpenGL
where Wolfgang called for serious developers to get in touch with him and he
would see what could be done about getting access to the NDA'ed Glamo
documents [1].  A couple of developers responded saying they were
interested.  I would like to see how many people are interested and willing
to commit to working on and OpenGL driver in this thread.  If there is
enough interest I will start a project one projects.openmoko.org and then we
can work with Openmoko on the legal aspects of the NDA.

So please, if you are interested and motivated lets discuss it here, then we
can work on getting the rest in motion.

Thanks,
Jacob
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community