Vsync on Glamo
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Tue Feb 17 08:00:24 CET 2009
On Mon, 16 Feb 2009 17:40:41 +0000 Thomas White <taw at bitwiz.org.uk> said:
> On Thu, 12 Feb 2009 18:08:56 +0530
> Andy Green <andy at openmoko.com> wrote:
> > If there was an effort to synthesize a VSYNC interrupt on Glamo (the
> > real thing doesn't exist), is there actually anyone who would use it?
> > Trying to figure out whether to close this as WONTFIX or have a go at
> > it.
> I noticed the problems described in the ticket, e.g. tearing of the
> green oscillating rectangle which appears during startup. Sharp
> vertical edges moving horizontally are of course the worst possible for
> showing up tearing.
> However, in that case, is it likely that it's more to do with the slow
> video bus (combined with single-buffered, non-accelerated graphics)
> than with the timings? Any estimates of how long the synchronisation
> interval would be? If it's shorter than the time needed for a redraw,
> then for single buffered graphics I can't see it making any
the rendering is actually double-buffered. the problem is yes - copies to video
ram from the back-buffer (which in this case is an mit-shm buffer) will simply
take much longer than a normal memcpy so its much more likely to catch it in
the middle of writing during a refresh.
> For the forthcoming 3D stuff, updates to the visible framebuffer will
> be happening by a (fast) hardware blit (I don't pretend to understand
> the more wider details of how/if X uses double buffering, but a blit
> operation is normal for Mesa). If there are tearing problems then,
you can do this with a fast 2d blit currently - draw to pixmap and then
xcopyarea - ecore_evas has this all there (enable avoid_damage). this adds
latency to drawing though and will impact framerate. gl doesnt magically solve
this. better than copying is to swap buffers - literally swap the frameubffer
pointer. this is only sane and doable for fullscreen windows though. (we can
argue about hacks to do it without with a reverse-copy - but i'll not go
there). gl will also put you in the boat of limited resolution and not being
able to do 3d in any buffer exceeding 511x511 - so you'll be dropping to 1vga
just to sanely do it.
> then I think this an emulated vsync would be useful for us. However, I
> think it'd be better to cross that bridge when we get to it.
> Has anyone noticed tearing with things that are definitely accelerated
> using EXA?
vsync will be pretty useless for all but GL. technically the x sync extension
can support vsync as a sync source for 2d. x could support it for double-buffer
extension enabled windows. but pretty much any vsync comes with the caveat of
ALSO having to redraw the whole screen for every update. that's good for 3d
games - they modify the whole screen. it is close to useless for generic 2d
unless done very carefully as 2d performance will suck so badly it won't be
funny if you force whole screen redraws... unless you can get gl-es 1.1 running
at vga res... and still be sane.
imho - worry about vsync when you have performance and featureset in general
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the devel