Vsync on Glamo
andy at openmoko.com
Tue Feb 17 02:18:12 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| 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
Well whatever the truth about being able to update that rectangle in one
frame == ~16ms, because the update action is not locked to anything you
will get some tearing. If it is too slow, but we do use VSYNC, the
tearing will at least become consistent.
| 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,
| 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?
FWIW Glamo has a page flip scheme where it can meddle the framebuffer
start address in memory automatically per-VSYNC... this is a "dumb" flip
because the processor is not aware of it due to lack of the interrupt
source. So you still have to poll it to see what page it has flipped to.
I would say VSYNC could be useful for mplayer type stuff but there what
you said is definitely true, we are way too slow to update the whole
framebuffer inside one VSYNC so it's pointless and will tear anyway, if
the page flip thing is used to hide it we can do without a synthetic VSYNC.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the devel