On Tue, 07 Apr 2009 11:35:41 -0400 "Iain B. Findleton"
said:
this is one of the problems with glamo. as i know it will not be used in any
future products beyond gta02. no other phones i know use it - no other linux
devices. writing an app totally around the glamo and how it works or doesnt
work w
That should be fine.
Of course, if the phone has no future
Thomas White wrote:
> On Fri, 03 Apr 2009 21:14:16 +0100
> Ian Stirling wrote:
>
>
>>> What is the bandwidth for memory moves?
>>>
>> About 6-8 or so - with 100% CPU utilisation
>>
>
> Or "one pixel per 2D engine clock
On Fri, 3 Apr 2009 15:14:35 +0200
ri...@happyleptic.org wrote:
> Which fits very well with what I call a closed system.
> What if I just want to have a look, and, depending on the chip
> capabilities and some experiments, decide to go lowlevel or not ?
A fair point...
T
On Fri, 03 Apr 2009 21:14:16 +0100
Ian Stirling wrote:
> > What is the bandwidth for memory moves?
>
> About 6-8 or so - with 100% CPU utilisation
Or "one pixel per 2D engine clock cycle" for moves inside Glamo's memory
using its blitter (i.e. VRAM->VRAM). I think that in the Freerunner
the re
On Sat, 4 Apr 2009 15:04:27 +0200
Rask Ingemann Lambertsen wrote:
>The Glamo doesn't have a vblank interrupt. Try to search the bug
> tracker, though, because there was a mention of an alternative means
> of getting double buffering to work.
Not having a vblank interrupt doesn't rule out dou
s a while back about making use of the
> >>> XGlamo acceleration features. Has any progress been made here? It
> >>> appears to me that the graphics performance on the FR is poor compared
> >>> to, for instance, the iPhone or iTouch, both of which have slower CPUs.
>
Rask Ingemann Lambertsen writes:
> Btw, what is the state of xf86-video-glamo?
I have been using xf86-video-glamo since Feb 25 and it[1] seems to be
quite stable.
> Does XVIDEO work?
xdpyinfo advertises Xvideo. My normal .mplayer/config has
framedrop=yes
vo=x11
quiet=yes
and with that at leas
On Fri, Apr 03, 2009 at 11:36:39AM +0100, Thomas White wrote:
> We do have some acceleration already - both XGlamo (the Kdrive X server)
> and xf86-video-glamo (the Glamo driver for Xorg) make use of Glamo's 2D
> engine to accelerate tasks such as flood-filling large areas and moving
> blocks of d
On Sat, 4 Apr 2009 15:33:26 +0200 Rask Ingemann Lambertsen
said:
> On Fri, Apr 03, 2009 at 09:14:16PM +0100, Ian Stirling wrote:
> > Iain B. FIndleton wrote:
>
> > > I
> > > wonder what the issue is in moving the frame buffer data? At the speeds
> > > available on the FR, moving 640 x 480 x 2
On Fri, Apr 03, 2009 at 09:14:16PM +0100, Ian Stirling wrote:
> Iain B. FIndleton wrote:
> > I
> > wonder what the issue is in moving the frame buffer data? At the speeds
> > available on the FR, moving 640 x 480 x 2 = 614,400 bytes from memory to
> > a video buffer at 30 Hz needs about 18 MB/s
On Thu, Apr 02, 2009 at 09:19:45PM -0400, Iain B. FIndleton wrote:
> Well, that clears things up a bit. So, there is no way to get rid of the
> draping one sees when the display is refreshed? My stuff uses double
> buffering, but your comments appear to indicate that that is a waste of
> time.
Iain B. FIndleton wrote:
> It appears to me that the implementation on the FR is not capable of
> moving an updated frame buffer in memory to the chip's video buffer,
> presuming they are different, without draping. Since the controller
> appears to be able to rescan its own video buffer without
On Fri, 3 Apr 2009 15:03:09 +0200
Nicola Mfb wrote:
> Some time ago we focused about the wasting of cpu cycles to wait for X
> operations to complete (as no interrupts are exported to userspace).
> This impacts a lot the system as you use accelerated graphics but you
> have to hold and wait for i
It appears to me that the implementation on the FR is not capable of
moving an updated frame buffer in memory to the chip's video buffer,
presuming they are different, without draping. Since the controller
appears to be able to rescan its own video buffer without flicker, I
wonder what the issu
On Fri, 3 Apr 2009 14:25:48 +0100 Thomas White said:
> On Sat, 4 Apr 2009 00:01:16 +1100
> Carsten Haitzler (The Rasterman) wrote:
>
> > beware of jumping all over 3d as the solution. i have recently been
> > working on a gles2 engine for evas. i have run it on 2 platforms
> > (s3c6410 and omap
On Sat, 4 Apr 2009 00:01:16 +1100
Carsten Haitzler (The Rasterman) wrote:
> beware of jumping all over 3d as the solution. i have recently been
> working on a gles2 engine for evas. i have run it on 2 platforms
> (s3c6410 and omap3530). both with hardware opengles2 (and capable of
> high res etc.
> In case we use an application that could take advantage to the screen
> resolution we
> could launch it forcing the X-windows server to change to vga resolution.
$ xvidtune -next
Xlib: extension "XFree86-VidModeExtension" missing on display ":0.0"
Unable to query video extension version
:-(
_
-[ Fri, Apr 03, 2009 at 01:37:22PM +0100, Thomas White ]
> > The main one being of course the lack of documentation.
>
> (Seriously, the necessary documentation has been released, under NDA, to
> people who have said they're serious about working on drivers).
Which fits very well with what I
2009/4/3 Thomas White
> [...]> The main one being of course the lack of documentation.
>
> The stack of paper on my desk says otherwise... :)
>
> (Seriously, the necessary documentation has been released, under NDA, to
> people who have said they're serious about working on drivers).
>
Some time
aking use of
> >> the XGlamo acceleration features. Has any progress been made here? It
> >> appears to me that the graphics performance on the FR is poor
> >> compared to, for instance, the iPhone or iTouch, both of which have
> >> slower CPUs. When applications
2009/4/3 Iain B. FIndleton
> In my case, one of the motivations for looking into the FR was the VGA
> graphics capability. Any old phone would do for QVGA level performance.
> As for the ferrari analogy, as far as graphics performance goes, it
> looks like the Apple produces and their
On Fri, 3 Apr 2009 14:12:55 +0200
ri...@happyleptic.org wrote:
> -[ Fri, Apr 03, 2009 at 11:36:39AM +0100, Thomas White ]
> > There are many limitations of the chip,
>
> The main one being of course the lack of documentation.
The stack of paper on my desk says otherwise... :)
(Seriously, th
(hopefully) faster Qt distros?
Regards
Juan Lucas
In my case, one of the motivations for looking into the FR was the VGA
graphics capability. Any old phone would do for QVGA level performance.
As for the ferrari analogy, as far as graphics performance goes, it
I installed whatever editor I use on the phone, then use a forwarded X
connection to do editing stuff using the desktop or portable. Fat thumb
typing on a small screen does not make a lot of sense to me, but then, I
don't text people much either.
joa...@verona.se wrote:
> ri...@happyleptic.
ogress been made here? It
>> appears to me that the graphics performance on the FR is poor
>> compared to, for instance, the iPhone or iTouch, both of which have
>> slower CPUs. When applications running on the FR have their X output
>> routed to a machine with accelerated gra
In my case, one of the motivations for looking into the FR was the VGA
graphics capability. Any old phone would do for QVGA level performance.
As for the ferrari analogy, as far as graphics performance goes, it
looks like the Apple produces and their competitors make the FR look
like the poor
-[ Fri, Apr 03, 2009 at 11:36:39AM +0100, Thomas White ]
> There are many limitations of the chip,
The main one being of course the lack of documentation.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/ma
ri...@happyleptic.org writes:
>> I feel the "ferrari" analogy is broken. it depends on what you would
>> like to do with the device. Moving bling bling is not efficient, Ok.
>> Things that demand high resolution, like ebooks and emacs work fine.
>
> I spend some time in the terminal myself, genera
It
> appears to me that the graphics performance on the FR is poor
> compared to, for instance, the iPhone or iTouch, both of which have
> slower CPUs. When applications running on the FR have their X output
> routed to a machine with accelerated graphics, it is apparent that
> the FR
> I feel the "ferrari" analogy is broken. it depends on what you would
> like to do with the device. Moving bling bling is not efficient, Ok.
> Things that demand high resolution, like ebooks and emacs work fine.
I spend some time in the terminal myself, generally to fix something in a
config file
On Fri, 2009-04-03 at 10:29 +0200, joa...@verona.se wrote:
> ri...@happyleptic.org writes:
>
> > -[ Fri, Apr 03, 2009 at 09:45:37AM +0200, Miguel Ángel Calderón ]
> >> What really surprises me is the fact that if this is so clear, why is
> >> Comunity not working on qvga graphics yet?
> >> (..
On Fri, 03 Apr 2009 10:29:07 +0200 joa...@verona.se said:
> ri...@happyleptic.org writes:
>
> > -[ Fri, Apr 03, 2009 at 09:45:37AM +0200, Miguel Ángel Calderón ]
> >> What really surprises me is the fact that if this is so clear, why is
> >> Comunity not working on qvga graphics yet?
> >> (..
ri...@happyleptic.org writes:
> -[ Fri, Apr 03, 2009 at 09:45:37AM +0200, Miguel Ángel Calderón ]
>> What really surprises me is the fact that if this is so clear, why is
>> Comunity not working on qvga graphics yet?
>> (...)
>> I'd prefer to drive the funnier modest car than to have the ferra
-[ Fri, Apr 03, 2009 at 09:45:37AM +0200, Miguel Ángel Calderón ]
> What really surprises me is the fact that if this is so clear, why is
> Comunity not working on qvga graphics yet?
> (...)
> I'd prefer to drive the funnier modest car than to have the ferrary parked
> outside... I though linux
On Fri, 3 Apr 2009 09:45:37 +0200 Miguel Ángel Calderón
said:
> 2009/4/3 Carsten Haitzler
>
> >
> >
> > so the other side of that is to do everything with the cpu in system ram
> > and
> > transfer to the glamo when done - so you only deal with the slow write
> > once, at
> > the end. but remem
2009/4/3 Carsten Haitzler
>
>
> so the other side of that is to do everything with the cpu in system ram
> and
> transfer to the glamo when done - so you only deal with the slow write
> once, at
> the end. but remember the write - when being done, will hold the cpu
> hostage
> and as it is now sl
r me is the performance of the graphics display on
> >>> the FR. I recall some discussions a while back about making use of the
> >>> XGlamo acceleration features. Has any progress been made here? It
> >>> appears to me that the graphics performance on the FR is po
leration features. Has any progress been made here? It
>>> appears to me that the graphics performance on the FR is poor compared
>>> to, for instance, the iPhone or iTouch, both of which have slower CPUs.
>>> When applications running on the FR have their X output routed
It
> appears to me that the graphics performance on the FR is poor compared
> to, for instance, the iPhone or iTouch, both of which have slower CPUs.
totally incorrect.
1. iphone ant itouch have 500-600mhz (depending on version) s3c6400 cpu cores.
these are about 2x the speed of the 244
Has any progress been made here? It
> > appears to me that the graphics performance on the FR is poor compared
> > to, for instance, the iPhone or iTouch, both of which have slower CPUs.
> > When applications running on the FR have their X output routed to a
> > machine with
Iain B. FIndleton wrote:
> A significant issue for me is the performance of the graphics display on
> the FR. I recall some discussions a while back about making use of the
> XGlamo acceleration features. Has any progress been made here? It
> appears to me that the graphics perfor
A significant issue for me is the performance of the graphics display on
the FR. I recall some discussions a while back about making use of the
XGlamo acceleration features. Has any progress been made here? It
appears to me that the graphics performance on the FR is poor compared
to, for
42 matches
Mail list logo
