Carsten Haitzler (The Rasterman)
raster at rasterman.com
Fri Apr 3 15:01:16 CEST 2009
On Fri, 03 Apr 2009 08:25:35 -0400 "Iain B. FIndleton"
<ifindleton at videotron.ca> said:
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.) and software beats
gles2. yes - evas software rendering is faster. oddly enough the movial guys
and trolltech (qt) guys see the exact same performance problems. gl is slower
(i know that i and the trolls have seen about a 1/4 speed of gl vs software).
reality bites :(
> In my case, the apps I use need space on the screen for buttons, etc
> that control the things being done. My typical layout is to use 460 x
> 570 for the actual application display, the rest for decorations and
> controls. Under these conditions, 512 x 512 would be fine, even if I had
> to cut the display by a few lines.
> Even the 2D accelerations items would probably make things much better
> as I do my own conversion from 3D to 2D.
> Are there any instructions as to how to get the xorg driver running? I
> currently use whatever came with the phone run time images
> Thomas White wrote:
> > On Thu, 02 Apr 2009 11:17:42 -0400
> > "Iain B. FIndleton" <ifindleton at videotron.ca> 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 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 processor can deliver the X events fast enough, but the FR
> >> graphics chip interface can't keep up.
> > [I wrote this before the other replies came through, so it re-covers a
> > bit of ground.]
> > 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 data around the screen or onto the screen from offscreen.
> > However, I do agree that we can do a lot more. So far, we've
> > concentrated on trying to implement conventional acceleration protocols
> > while being limited by what Glamo can't do. Instead, I think we should
> > look at what the little chip CAN do, and really make it work, HARD, for
> > us. Particularly its 3D engine. With that, we could do things like
> > (dare I say it, iPhone-style) flying launcher icons, or alpha-blended
> > overlays, or other things I can't even imagine right now...
> > There are many limitations of the chip, but I don't see them as a
> > reason to give up on this kind of thing. For example, it's often
> > mentioned that the 3D engine won't render to a buffer larger than
> > 511x511 pixels. That would seem to rule out such graphical fanciness
> > at the native resolution of 480x640, but how about we just cover a
> > 480x511 region of the screen with accelerated graphics and make the
> > remaining area into some kind of tool or status bar? Maximum texture
> > size of 256x256? Then design the UI so that the accelerated parts of
> > the UI split into blocks of that size or less. And so on.
> > I see more potential in working 3D acceleration than just Quake, and
> > I'm not in the least bit put off by the knowledge that the chip is a
> > "one-off"...
> > Tom
> > _______________________________________________
> > Openmoko community mailing list
> > community at lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> Openmoko community mailing list
> community at lists.openmoko.org
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the community