Graphics Performance

[Carsten Haitzler (The Rasterman)]

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


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