On 06/08/2013 11:18 AM, Daniel Stone wrote:
Hi,
On 7 June 2013 13:30, James Jones <[email protected]> wrote:
We do need more than the 'make it pretty' requirement above though. What you
describe is what interactive rendering apps want, when you're translating
some sort of input into graphics with as little latency as possible.
Video/streaming apps would rather queue up several frames as close to the HW
presentation mechanism as possible to avoid hiccups, but have precise
control over when the frames present so they can still do A/V sync right
with the longer queues. That's where the OML-type stuff with counters and
timers becomes interesting. Those are the two important scenarios I know of
right now. I can't say for certain others don't exist.
This is only true to the extent that the entire pipeline is totally
predictable in terms of latency;
That doesn't sound right to me. I would think you want what I described
above in high-latency or fluctuating latency situations, where you want
to accurately do something a few hundred milliseconds in the future,
rather than inaccurately do something ASAP. The synchronization is
supposed to happen at the end of the pipeline, where more accuracy is
possible.
given that isn't even remotely true
with these kinds of system, timing feedback, to allow clients to
adjust accordingly, is more important. GStreamer, for example, has
really detailed code to feed back in frame timestamps and use the
actual, rather than predicted, presentation time to adjust its clock.
Yes, if your system doesn't allow accurate semi-high latency
presentation, that's what you'd want. This idea is for a system that
does allow accurate presentation after a series of
maybe-not-so-predictable-latency operations though. I think ideally,
you have both: A framework that allows reliable latency when the
HW/driver supports it, AND accurate feedback to handle the situations
where the driver or hardware can't provide sufficiently reliable
presentation. I'm certainly not opposed to feedback mechanisms.
This isn't theoretical either. We have robust implementations of the
high latency/accurate mechanism in VDPAU and GL_NV_present_video:
ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/group___vdp_presentation_queue.html
http://www.opengl.org/registry/specs/NV/present_video.txt
The general "list of fences" mechanism is theoretical at the moment, but
is the logical next step in generalizing both the high latency/reliable
and low-latency/best effort mechanisms IMHO. Over the past few years,
it's proven interesting to have mechanisms to synchronize graphics
processing at the front and end of the graphics pipeline (GL fences, EGL
fences, X fence syncs to a lesser extent). Having a similarly powerful
way to express synchronization at the beginning of the display pipeline
seems like it could be a useful tool as well.
Thanks,
-James
Cheers,
Daniel
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
